System and method for securing electronic games

ABSTRACT

A game server is provided, the game server comprising a processor and a storage device coupled to the processor. The storage device stores instructions adapted to be executed by the processor to perform a method comprising: generating a first signal; transmitting an encoded first signal; receiving a second signal; and transmitting a decoding key after receiving the second signal.

[0001] This application is a continuation-in-part application of U.S.patent application Ser. No. 09/895,648, filed Jun. 29, 2001; which is acontinuation of U.S. patent application Ser. No. 09/488,608; which is acontinuation of U.S. patent application Ser. No. 08/775,588; thecontents of each of which are incorporated by reference herein for allpurposes.

FIELD OF INVENTION

[0002] The present invention relates to electronic games, andparticularly to methods and devices for securing and ensuring therandomness of electronic or online games.

BACKGROUND OF THE INVENTION

[0003] Various forms of electronic games of chance have been availablefor many years. The way these games are played, however, is changingdramatically with the use of digital computers operating on electronicnetworks such as the Internet. Players can now connect to a remoteserver and wager electronically.

[0004] Rather than traveling to a casino, a player can log into anelectronic game and wager from the comforts of his own home. While thisremote playing has many advantages, it raises several security issues.For example, when playing card games at a casino, a player can observethe dealer shuffle and deal the cards and thus has some confidence thatthe outcome was generated randomly. In an electronic casino, theshuffling process is typically digitally generated, driven by randomnumber generators which the player cannot see. The player cannot knowwhether the random number generated is truly random or was selected bythe casino to give it an advantage.

[0005] Electronic game providers have tried to increase players'confidence in the legitimacy of games by assuring players that gamingsoftware has not been tampered with. For example, an electronic gameprovider may allow an independent third party to perform an audit of thesoftware. This is a time-consuming and expensive process, however. Withcomplex software running into the hundreds of thousands of lines ofcode, it is very difficult to find a few lines of code that alter therandomness of the outcomes.

[0006] Some electronic lottery systems have subscribed to methods forsecuring communications between remote player terminals and a centralcontroller. U.S. Pat. No. 4,652,998 to Koza, for example, describescryptographic methods for securing these communications. In gamesdependent on the use of random numbers, however, simply securing thetransmission of a fraudulent random number does not solve the problemsinherent in the prior art.

[0007] Although there are many patents which describe the generation ofrandom numbers, such as U.S. Pat. No. 3,548,174 to Knuth, they describeonly methods for improving the statistical performance of random numbergenerators.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The accompanying drawings, which are incorporated in andconstitute a part of this specification, illustrate several embodimentsof the invention and together with the general description given aboveand the detailed description given below, serve to explain theprinciples of the invention.

[0009]FIG. 1 is a block diagram of an electronic game system inaccordance with some embodiments of the present invention.

[0010]FIG. 2 is a block diagram showing some embodiments of a gameserver.

[0011]FIGS. 2A and 2B are block diagrams showing exemplary databaseconfigurations.

[0012]FIG. 3 is a block diagram showing some embodiments of a playerterminal.

[0013]FIG. 4 is a flow chart illustrating an exemplary process by whicha player transmits a selection to a game server.

[0014]FIG. 5 is a flow chart showing an exemplary process by which aplayer generates and encodes a random number.

[0015]FIG. 6 is a flow chart illustrating an exemplary process by whicha game server generates and encodes a random number.

[0016]FIG. 7A is a flow chart illustrating an exemplary process ofexchanging decoding keys between a player terminal and a game server.

[0017]FIG. 7B is a flow diagram illustrating an exemplary exchange ofencoded random numbers and decoding keys between a player terminal and agame server.

[0018]FIG. 8 is a flow chart illustrating an exemplary process ofgenerating a game result based on a combination of a first random numberand a second random number.

[0019]FIG. 9 is a flow chart illustrating an exemplary process ofgenerating and transmitting a random number without encoding it.

[0020]FIG. 10A is a flow chart illustrating an exemplary process oftransmitting a decoding key from a player terminal to a game server anddecoding a random number.

[0021]FIG. 10B is a flow diagram illustrating the process oftransmitting an encoded random number from a player terminal to a gameserver, transmitting an unencoded random number from the game server tothe player terminal, and transmitting a decoding key from the playerterminal to the game server.

[0022]FIGS. 11 through 13A are flow charts illustrating variousexemplary procedures for exchanging random numbers in which a playerterminal generates a hash value of a random number.

[0023]FIG. 13B is a flow diagram illustrating an exemplary exchange ofhash values of random numbers, and subsequently the random numbersthemselves, between a player terminal and a game server.

[0024]FIG. 14 is a flow chart illustrating an exemplary procedure forsimultaneously exchanging random numbers between a player terminal and agame server.

[0025]FIG. 15 is a flow chart illustrating an exemplary procedure forencoding and decoding a player communication using a symmetric key.

[0026]FIG. 16 is a flow chart illustrating an exemplary procedure forencoding and decoding a player communication using asymmetric keys.

[0027]FIG. 17 is a flow chart illustrating an exemplary procedure forproviding authentication and message integrity.

[0028]FIG. 18 is a flow chart illustrating another exemplary procedurefor providing authentication and message integrity.

[0029]FIG. 19A is a flow chart illustrating an exemplary process forgenerating multiple decoding keys.

[0030]FIG. 19B is a flow diagram indicating the generation of multiplenumbers by a game server.

DETAILED DESCRIPTION OF THE INVENTION

[0031]FIG. 1 illustrates the basic system components of one or moreembodiments of the present invention. Generally, the system comprisesgame server 200 and multiple player terminals 300, each with anassociated player modem 350. Game server 200 preferably is incommunication with the player terminal modems 350 via an Internetconnection using a network 110, such as a Public Switched TelephoneNetwork (“PSTN”). Alternatively, communication may take place viadedicated data lines, cellular, Personal Communication Systems (“PCS”),microwave, satellite networks, or any other form of data communicationspath.

[0032] Optionally, game server 200 and/or one or more player terminals300 may be in communication with a third party 295. Receiving and/ortransmitting of various types of information may take place via theoptional third party 295, as described in detail below.

[0033] Any number of gaming devices and/or optional third parties may bein communication with the server 200. The number of each depicted inFIG. 1 is solely for purposes of illustration.

[0034]FIG. 2 illustrates the basic hardware and data structures of gameserver 200 in accordance with one or more embodiments of the presentinvention. Game server 200 includes central processor (“CPU”) 205,cryptographic processor 210, random access memory (“RAM”) 215, read-onlymemory (“ROM”) 220, random number generator 225, payment processor 230,clock 235, operating system 240 (typically residing in memory assoftware), network interface 245, and data storage device 250. Theseelements are connected appropriately, for example, by a standard systembus, so as to allow communications among them.

[0035] Game server 200 is preferably capable of high volume transactionprocessing, performing a significant number of mathematical calculationsand processing communications and database searches. In one or moreembodiments, game server 200 comprises a conventional personal computeror computer workstation with sufficient memory and processing capabilityto perform the disclosed functionality. A processor such as the 1.8 GHZPentium® 4, commonly manufactured by Intel Inc., may be used for CPU205. In other embodiments, game server 200 operates as a Web server,both transmitting and receiving communications to and from playerterminals 300.

[0036] Cryptographic processor 210 supports the encoding and decoding ofcommunications with players, as well as the authentication of players.An MC68HC16 microcontroller, commonly manufactured by Motorola Inc., maybe used for cryptographic processor 210. This microcontroller utilizes a16-bit multiply-and-accumulate instruction in the 16 MHZ configurationand requires less than one second to perform a 512-bit private keyoperation. Other exemplary commercially available specializedcryptographic processors include VLSI Technology's 33 MHz 6868 orSemaphore Communications' 40 MHZ Roadrunner 284. Alternatively,cryptographic processor 210 may be configured as part of CPU 205.

[0037] As used herein, encoding and decoding refer to any method ofdisguising and revealing a message or signal, respectively. Thesemethods include the use of key-based algorithms, codes, steganography,substitution ciphers, transposition ciphers, one-time pads, hashfunctions, and so on, including various combinations of any suchtechniques. For a more complete list of encoding and decodingtechniques, see Bruce Schneier, Applied Cryptography: Protocols,Algorithms, and Source Code in C, (2^(nd) ed., John Wiley & Sons, Inc.,1996). Cryptographic processor, 210, may support any of thesetechniques. A conventional random number generating processor may beused for random number generator 225. The HEMT integrated circuitmanufactured by Fujitsu, for example, is capable of generating over onebillion random numbers per second. Alternatively, random numbergenerator 225 may be incorporated into CPU 205.

[0038] Payment processor 230 supports the transfer and exchange ofpayments, charges, or debits. Functions performed by payment processor230 include the preparation of on-line account statements, order-taking,credit card payment authorization, credit card settlement, automatedsales tax calculations, digital receipt generation, account-basedpurchase tracking, and payment aggregation for low-priced services.Processing of credit card transactions by payment processor 230 may besupported with commercially available software, such as the SecureWebserver manufactured by Open Market, Inc. This server softwaretransmits credit card numbers electronically over the Internet toservers located at the Open Market headquarters where card verificationand processing is handled. Their Integrated Commerce Service providesback-office services necessary to run Web-based businesses. Paymentprocessor 230 preferably comprises a microprocessor (such as the IntelPentium® 4), but alternatively may be configured as part of CPU 205.

[0039] Data storage device 250 may include hard disk, magnetic, oroptical storage units, as well as CD-ROM drives or flash memory. Datastorage device 250 contains databases used in the processing oftransactions in the present invention, including player database 255,player selection data database 260, game result database 265, playerrandom number database 270, player decoding key database 275, auditdatabase 280, payment database 285, player account database 290, gameserver random number database 292, game server encoding key database294, game server decoding key database 296, and combination protocoldatabase 298. In a preferred embodiment, database software such asOracle9i™, manufactured by Oracle Corporation, is used to create andmanage these databases.

[0040] For illustration purposes, FIG. 2A provides a structural diagramof an exemplary player selection data database 260. As shown, selectiondata database 260 maintains data on selections made by a player, andincludes fields for saving player ID number 261, tracking number 262,game selected 263, amount of wager 264, time of wager 266, type of wager267, and a game result 268.

[0041]FIG. 2B illustrates another example of a database, this time, thegame result database 265. As shown, game result database 265 tracks theresults associated with each set of player selection data and includesfields for the player ID number 261, selection data tracking number 262,game result 268, result value 269, time of result 271, and status ofpayment 272.

[0042] The meaning of the information in these various fields willbecome more clear in the following descriptions. The other databases areorganized in a similar manner, thus separate figures of each are notnecessary. Player database 255 maintains data on players, and includesfields such as name, address, credit card number, phone number, IDnumber, social security number, electronic mail address, past systemusage, public/private key information, and game preferences. Thisinformation is preferably obtained when the player first registers withthe system. Player database 255 also contains the tracking number ofeach player selection data and player random number generated by aplayer.

[0043] Player random number database 270 stores all player randomnumbers. This database is indexed by player ID and contains fields suchas player ID number, corresponding selection data tracking number,tracking number of a corresponding player decoding key, a player randomnumber, and the time at which the player random number was received bygame server 200.

[0044] Player decoding key database 275 facilitates the decoding of theplayer random number, storing the keys necessary to decodecommunications from a player. For messages encrypted using a public keyencryption system such as RSA, Data Security Inc.'s player public keyswill be stored in player decoding key database 275. In a symmetric keycryptographic system such as Data Encryption System (“DES”), symmetrickeys are stored. Both symmetric and public keys are long strings ofbinary digits, and are explained more fully below with respect tocryptographic authentication embodiments.

[0045] Audit database 280 stores transactional information relating to aplayer and, in one or more embodiments, includes the time and date ofeach player log in, and the number of games played.

[0046] Payment database 285 tracks all payments made by the players withfields such as player name, player ID number, amount of payment, andcorresponding player selection data and a game result. This database mayalso store credit card numbers of players or bank account information.

[0047] Player account database 290 may be established if the playerwants to keep a balance of funds at game server 200 for futuretransactions. Player account database 290 acts as a checking account,with winnings deposited and losing wagers subtracted. Alternatively,this account may be a pointer to account data stored at the player'sbank, storing only the name of the bank and the player's bank accountnumber.

[0048] Game server random number database 292 tracks all game serverrandom numbers generated by game server 200 and, in one or moreembodiments, includes fields such as corresponding player selection datatracking number, player name, player ID number, the time that gameserver random number was generated, and the time that the game serverrandom number was transmitted to the player.

[0049] Game server encoding key database 294 stores all encoding keysused by game server 200 to encode the game server random number.

[0050] Game server decoding key database 296 stores all decoding keystransmitted to player terminal 300 to decode the game server randomnumbers.

[0051] Finally, combination protocol database 298 stores the protocolsused to combine a player random number with a game server random numberto form a result value.

[0052] Referring again to FIG. 2, network interface 245 is the gatewayto communicate with players through respective player terminals 300.Conventional internal or external modems may serve as network interface245. Network interface 245 preferably supports modems at a range of baudrates from 1200 upward, but may combine such inputs into a T1 or T3 lineif more bandwidth is required. In a preferred embodiment, networkinterface 245 is connected to the Internet and/or a commercial on-lineservice such as America Online, CompuServe, or Prodigy, allowing playersaccess to game server 200 from a wide range of electronic connections.Several commercial electronic mail servers include the abovefunctionality. For example, NCD Software manufactures “Post. Office,” asecure server-based electronic mail software package designed to linkpeople and information over enterprise networks and the Internet. Thisproduct is platform independent and utilizes open standards based onInternet protocols. Users can exchange messages with enclosures such asfiles, graphics, video, and audio. This product also supports multiplelanguages. Alternatively, network interface 245 may be configured as avoice-mail interface, web site, electronic Bulletin Board System(“BBS”), or electronic-mail address.

[0053] While the above embodiment describes a single computer acting asgame server 200, those skilled in the art will realize that thefunctionality can be distributed over a plurality of computers, whereinthe databases and processors are housed in separate units or locations.Some controllers perform the primary processing functions and contain,at a minimum, RAM, ROM, and a general processor. Each of thesecontrollers is attached to a WAN hub which serves as the primarycommunication link with the other controllers and terminals. The WAN hubmay have minimal processing capability itself, serving primarily as acommunications router. Those skilled in the art will appreciate that analmost unlimited number of controllers may be supported.

[0054]FIG. 3 illustrates the basic hardware and data structures of aplayer terminal in accordance with a preferred embodiment of theinvention. Player terminal 300 preferably includes central processor(CPU) 305, cryptographic processor 310, RAM 315, ROM 320, random numbergenerator 325, video driver 327, video monitor 330, clock 335,communication port 340, input device 345, modem 350, and data storagedevice 360. Biometric device 355 may be added for increased security, asdescribed below with respect to cryptographic authenticationembodiments. A processor such as the 1.8 GHZ Pentium® 4 described abovemay be used for CPU 305. A conventional random number generatingprocessor such as the HEMT integrated circuit described above may beused for random number generator 325. Alternatively, random numbergenerator 325 may be incorporated into CPU 305. Clock 335 is a standardchip-based clock which can serve to time stamp transactions betweenplayer terminal 300 and game server 200.

[0055] In an exemplary embodiment, player terminal 300 is a conventionalpersonal computer having an input device, such as a keyboard, mouse, orconventional voice recognition software package. Player terminal 300would thus interface with game server 200 via modem 350. Alternatively,player terminal 300 may be a voice-mail system, or other electronic orvoice communications system. Devices such as fax machines or pagers arealso suitable terminal devices.

[0056] Modem 350 may not require high-speed data transfer if most playerselection data and player random numbers are text-based and not toolong. For cryptographic processor 310, the MC68HC16 microcontrollerdescribed above may be used. The structure of biometric device 355 willbe described in conjunction with the cryptographic authenticationembodiment.

[0057] Data storage device 360 preferably comprises a conventionalmagnetic-based hard disk storage unit such as those manufactured bySeagate. Selection data database 365 records all selection datagenerated by a player, tracking games selected, type of bet, amount ofwager, etc. Audit database 370 stores communications between playerterminal 300 and game server 200. Encoding key database 375 stores keysused in the process of encoding communications transmitted to gameserver 200. Combination protocol database 380 stores the protocols usedby game server 200 to combine a player random number and a game serverrandom number. Game result database 385 stores all of the players'results, including amounts won or lost. Player random number database390 stores each random number generated by a player. Game server randomnumber database 395 stores all game server random numbers received fromgame server 200. This database may also store the corresponding decodingkeys in the event that a game server random number is encoded.

[0058] Player terminal 300 communications are preferably softwaredriven. There are many commercial software applications that can enablethe communications required by player terminal 300, the primaryfunctionality being message creation and transmission. Eudora Promanufactured by Qualcomm Incorporated, for example, provides editingtools for the creation of messages as well as the communications toolsto route the message to the appropriate electronic address. When gameserver 200 is configured as a Web server, conventional communicationssoftware, such as the Internet Explorer™ Web browser from MicrosoftCorporation may also be used. The player may use the Internet Explorer™browser to transmit and receive random numbers and selections.

[0059] Having described the system and component architecture, we willnow consider various embodiments of the present invention to ensure theintegrity of electronic games.

[0060] As discussed, in one or more embodiments of the presentinvention, communications between player terminal 300 and game server200 take place via one or more electronic networks, preferably with gameserver 200 acting as a Web server.

[0061]FIG. 4 illustrates a process by which a player transmits a playerselection to a game server. Initially, a player logs on to game server200 using player modem 350 of player terminal 300, establishing acommunication link at step 400. At step 410, the player selects the gamethat he wants to play by selecting from a list of possible games. Theplayer may, for example, select a potential game from a list on a Webpage by clicking on the appropriate icon or graphic. Games preferablyinclude casino games such as blackjack, craps, roulette, baccarat, slotmachines, lottery, poker, video poker, and sports betting, but mayinclude any game in which a first party (e.g., a server) generates arandom number that must be trusted by a second party (e.g., player),including raffles and prize drawings.

[0062] There are many types of games having a random component that arenot typically considered casino games or “games of chance.” For example,many board games, such as Scrabble™ or Monopoly™, as well as card games,such as Bridge or Hearts, may typically be considered “games of skill”or non-casino games. Many such games, however, have an element ofrandomness, such as a dice roll, a selection of letters, a shuffled deckof cards, and/or a deal of cards. Thus, any game in which one partygenerates a random number that must be trusted by another party may beprovided for in accordance with various embodiments of the presentinvention.

[0063] After the game is selected, the player selects a type of wager atstep 420. The type of wager is directly related to the game selected.The type of wager for a roulette game might be, for example, a bet on“even”, or a single number bet, such as “18 black.” For a game likeblackjack, the type of wager would indicate the number of simultaneoushands the player intends to play.

[0064] At step 430, the player then selects the amount of each wager.For example, the player might bet one hundred dollars on the nextblackjack hand, or may bet five dollars on the next pull of a slotmachine. The player may elect to use funds from player account database290 or may transmit payment information such as a credit card numberalong with the total amount wagered. At step 440, the player attacheshis name or a unique player ID number to his selections, allowing gameserver 200 to authenticate the identity of the player. This ID number ispreferably received from game server 200 when the player registers withthe service or is chosen by the player and then registered with gameserver 200 by phone. As shown in FIG. 2A, game server 200 maintains adatabase of player ID numbers in player database 255 and issues (orallows) only unique numbers. If less security is required, the player'stelephone number could serve as the ID number since it has theadvantages of being both unique and easily remembered. If additionalsecurity is required, procedures such as those described below withrespect to cryptographic authentication embodiments may be implemented.

[0065] At step 450, all of the data provided by the player is combinedto form “selection data” which is transmitted to game server 200. Gameserver 200 then receives the player selection data and adds a trackingnumber before storing it in selection data database 260.

[0066] Instead of a World Wide Web-based interface, players may alsotransmit the selection data via electronic-mail, voice-mail, orfacsimile transmissions. With voice-mail, the player calls game server200 and leaves selection data in audio form. Selection data is thentranscribed into digital text at game server 200 by a conventionalaudio-to-text transcriber, not shown. As described, game server 200supports a plurality of transmission methods, allowing for a widevariety of formats of selection data.

[0067] The selection data need not include each of a type of game, atype of wager, and the amount of a wager. In some embodiments, a type ofwager and/or an amount to wager may be stored at the game server asplayer preferences, for example, in player database 255. For example,the player may only need to indicate a type of game in the selectiondata, and the game server may look up the player's preferences for typeof wager and/or amount of wager in player database 255 based on the typeof game. Of course, some types of games may be offered that do notrequire the player to make a wager at all. In some embodiments, the typeof game preferred by the player may be associated with the player as apreference, for example, in player database 255. Accordingly, in one ormore embodiments of the present invention, the player selection data maynot include a type of game, a type of wager and/or a wager amount.

[0068]FIG. 5 illustrates a process by which a player generates andencodes a random number for use by the game server 200. At step 500, theplayer generates a player random number either by selecting a numberhimself or prompting random number generator 225 of player terminal 300to produce the number. Although this number is preferably random, thesystem works equally well with any number that cannot be predicted bygame server 200. Random number generator 225 may incorporate externalfactors, such as the time between keystrokes of the player, or thecurrent position of a computer mouse. At step 510, player terminal 300stores the player random number in player random number database 390. Atstep 520, cryptographic processor 310 encodes the player random numberusing an encoding key from encoding key database 375. Because eachplayer random number preferably uses a unique encoding key, encoding keydatabase 375 preferably contains either a large number of unique keys orgenerates new encoding keys in real-time. Various methods for encodingnumbers are known in the art and need not be described here in detail.For reference, one of ordinary skill in the art may refer to BruceSchneier, Applied Cryptography: Protocols, Algorithms, and Source Codein C, (2^(nd) ed., John Wiley & Sons, Inc., 1996).

[0069] As noted above, a number transmitted by one party to another foruse in a combination protocol need not be a random number, but may beany number that cannot be predicted (or cannot be predicted easily) bythe other party. It will also be understood that the data transmittedfor use in a combination protocol may be any signal, data, orinformation that is unlikely to be predicted by the other party. Suchsignals may include, without limitation, one or more numbers, randomnumbers, letters, alphanumeric characters, audio signals, video signals,algorithms, or any combination of such information. Any such signals maybe selected by the party directly (e.g., a process for selecting asignal need not include any randomness). Although various embodimentsare described herein as relating to random numbers, it will beunderstood that the various embodiments may employ any of the signalsdescribed herein.

[0070] Along with an encoded player random number, the player appendshis player ID number and the tracking number (see FIG. 2A) to thecorresponding selection data so that game server 200 knows to whichwager the player random number should apply. This information is thentransmitted to game server 200 using player modem 350 at step 530. Inorder to authenticate the player's identity, game server 200 extractsthe player ID number from the message containing the encoded playerrandom number and looks up the player's identity in player database 255.If further authentication is desired, the protocols of theauthentication embodiments discussed below may be employed.

[0071]FIG. 6 illustrates a procedure used by game server 200 to generateand encode a game server random number. After authenticating a player,random number generator 225 of game server 200 generates a game serverrandom number at step 600. At step 610, the game server random number isstored in game server random number database 292. At step 620,cryptographic processor 210 of game server 200 encodes the game serverrandom number. As with the encoding of the player random number,cryptographic processor 210 preferably has access to a large supply ofunique encoding keys or an algorithm to produce them. At step 630, gameserver 200 then transmits encoded game server random number to playerterminal 300. It should be noted that there are a number of hardwareoptions for the receipt of the encoded game server random number atplayer terminal 300.

[0072] In this embodiment, the system remains secure because the randomnumbers have been generated and exchanged for future verification, buthave not yet been decoded. As such, both parties know that the randomnumbers have been generated independently, ensuring a fair game result.

[0073]FIG. 7A illustrates a procedure for exchanging decoding keysbetween the player terminal 300 and game server 200. At step 700, gameserver 200 (for the first time) transmits game server decoding key toplayer terminal 300. Like the encoding key used to encode the gameserver random number, the game server decoding key must be unique foreach random number generated. At step 710, the player terminal 300transmits a unique player decoding key to game server 200. In thisembodiment, this exchange of decoding keys need not take placesimultaneously since both parties are already in possession of eachother's encoded random number. At step 720, game server 200 uses theplayer decoding key to decode the player random number. At this point,game server 200 now has both a player random number and a game serverrandom number in decoded form and can use these numbers to generate agame result. The player need only decode the encoded game server randomnumber in the event of a dispute, as described below.

[0074]FIG. 7B illustrates, in flow diagram form, the process describedin FIGS. 5 through 7A. As illustrated, the player terminal 300ultimately transmits to the game server 200 both an encoded playerrandom number, E_(p)(M_(p)) (750) and a player decoding key D_(p) (760).The game server transmits to the player terminal both an encoded gameserver random number E₁(M₁) (740) and a game server decoding key D₁(730).

[0075]FIG. 8 illustrates a procedure for the game server 200 to generatea game result. As shown, game server 200 generates a game result basedon the game server random number and the decoded player random numberusing the combination protocol from combination protocol database 298(FIG. 2). At step 800, the combination protocol is retrieved fromcombination protocol database 298. The combination protocol ispreferably known to both the player terminal 300 and game server 200, isunique to the particular game selected, and may be published for anyoneto read. The combination protocol is preferably a series of mathematicalsteps which transform the player random number and the game serverrandom number into a distinct “result value.”

[0076] For example, a single game of roulette may have thirty-eightpossible outcomes, each outcome corresponding respectively to one of thethirty-eight positions on a roulette wheel. Therefore, an appropriatecombination protocol for a roulette game may be one that provides aresult value that is, for example, an integer between 0 and 37,inclusive (e.g., thirty-eight distinct values). Each result value canthen be mapped to an outcome on a roulette wheel, such as such as “1”,“2”, or “00”. In one example, the combination protocol developed for aroulette game may indicate that the player random number and the gameserver random number are first multiplied together, with the resultingnumber squared. This result is then added to the number 5. Theremainder, after dividing this resulting number by 38, is the “resultvalue.” The result value in this example, therefore, is an integerbetween 0 and 37, inclusive. For the roulette game, the possible resultvalues (e.g., the thirty-eight integers between 0 and 37, inclusive) aremapped with the set of thirty-eight possible outcomes for the spin of aroulette wheel. Thus, the result value corresponds to the result of thespin of a roulette wheel.

[0077] At step 810, the result value is then compared to the type ofwager in the player selection data in database 260 to determine a gameresult. For example, in the roulette example, a player making a bet on“fifteen-red” (see FIG. 2A) would lose the wager if the result valuewere any number other than “fifteen-red.” The game result for a lossmight be “lose one dollar” for a one dollar wager. At step 820, the gameresult is then transmitted to player terminal 300. Payment processor 230of game server 200 then decrements player account 290 by one dollar, orcharges the player's credit card one dollar (step 830), then stores thegame result in game result database 265, indexed by the player ID number(step 840). For an improved audit trail, in one or more embodiments thegame result is time stamped by clock 235 of game server 200 before beingstored, or is cryptographically chained to previously stored gameresults. The corresponding player selection data stored in selectiondata database 260 is then updated to indicate that a result has beenreached in step 850 (see e.g. the “result” column in FIG. 2). The playermay now begin the cycle again by selecting another set of playerselection data.

[0078] Using one or more of the methods described above, a player may beconfident that the random numbers were generated independently of oneanother. For game server 200 to cheat, it would have to decode theplayer random number before generating the game server random number.With knowledge of the player random number, game server 200 could selecta game server random number to obtain a desired result value and, hence,game result. Obtaining the player random number before generating thegame server random number, however, requires game server 200 to decodethe encoded player random number, which cannot be accomplishedpractically before receiving the player decoding key. If the playersuspects that game server 200 has cheated by not properly incorporatingthe player random number, he can decode the game server random numberusing the game server decoding key and apply the combination protocolfrom the combination protocol database 380 at the player terminal 300 toboth random numbers, thus verifying the game result.

[0079] In some embodiments of the present invention, player terminal 300and game server 200 exchange random numbers. In some embodiments bothparties transmit an encoded random number to the other party. In someembodiments, however, only one of the parties needs to encode its randomnumber. The party transmitting its random number without encoding therandom number preferably waits until it has received the coded randomnumber from the other party before transmitting its random number. Suchembodiments will now be discussed with reference to FIGS. 9 and 10A-10B.

[0080] Referring to FIG. 9, player terminal 300 has already generated aplayer random number, encoded it, and transmitted it to game server 200in a manner similar to that described for the mutual encodingembodiments. At step 900, game server 200 generates a game server randomnumber and, at step 910, stores it in game server random number database292. At step 920, game server 200 transmits the game server randomnumber to player terminal 300. Since no encoding takes place, however,game server 200 does not transmit a game server decoding key.

[0081] As shown in FIG. 10A, after receiving the game server randomnumber, player terminal 300 transmits a player decoding key to gameserver 200 at step 1000. At step 1010, game server 200 uses the playerdecoding key to decode the encoded player random number. At this point,each party is in possession of the other party's respective randomnumber. The random numbers are then combined as described above togenerate a game result.

[0082] In some embodiments, player terminal 300 generates and transmitsencoded player random number before game server 200 generates andtransmits the game server random number. Then, after receiving the gameserver random number, player terminal 300 transmits the decoding key forthe game server 200 to decode the encoded player random number. In oneor more alternative embodiments, game server 200 and player terminal 300switch procedures. Specifically, game server 200 generates and transmitsan encoded game server random number before player terminal 300generates and transmits the player random number. Then, after receivingthe player random number, the game server 200 transmits the decoding keyfor the player terminal to decode the game server random number shouldthe player so choose.

[0083]FIG. 10B illustrates, in flow diagram form, one or moreembodiments in which only one random number needs to be encoded. In FIG.10B, the player terminal 300 transmits to the game server 200, both theencoded player random number, E_(p)(M_(p)) (1030), and the playerdecoding key, D_(p) (1040). The game server 200 transmits to the playerterminal 300 only the game server random number M₁ (1020).

[0084] Again, in these embodiments, both the player and the game server200 may be confident that the player random number and the game serverrandom number were developed independently.

[0085] In one or more embodiments of the present invention, neitherplayer terminal 300 nor game server 200 encodes their respective randomnumbers. Instead, player terminal 300 generates a player random number,hashes it, sends the hash value to game server 200, and then receivesthe game server random number. The player terminal then transmits theplayer random number to game server 200, where it is hashed and thencompared to the hash value previously received to determine whether itis the number originally generated by player terminal 300. Operation ofthis embodiment is illustrated in the flow diagrams of FIGS. 11-13A.

[0086] Referring to FIG. 11, player terminal 300 has already transmittedplayer selection data to game server 200 as described above. At step1100, player terminal 300 then generates a player random number aspreviously described. At step 1110, the player random number is storedin player random number database 390 of player terminal 300.Cryptographic processor 310 then hashes the player random number at step1120, generating a hash value. This hash value represents a one-waytransformation of the original player random number. While it iscomputationally simple to generate the hash value from the player randomnumber, it is computationally unfeasible to re-create the player randomnumber from the hash value alone. At step 1130, player terminal 300transmits the hash value to game server 200.

[0087] As shown in FIG. 12, game server 200 then generates a game serverrandom number at step 1200. This number cannot be based on the playerrandom number since, in this embodiment, game server 200 only possessesthe hash value of the player random number. At step 1210, game server200 stores the game server random number in game server random numberdatabase 292, then, at step 1220, transmits the game server randomnumber to the player terminal.

[0088] Referring to FIG. 13A, player terminal 300 receives and storesthe game server random number at step 1300. At step 1310, playerterminal 300 then sends the unhashed player random number to game server200. At step 1320, cryptographic processor of the game server 200 hashesthe player random number, comparing the resulting hash value to the hashvalue received from player terminal 300. If the hash values match, thengame server 200 is assured that player terminal 300 has not submitted analtered player random number. With both random numbers now in itspossession, game server 200 then proceeds to generate a game result asdescribed above.

[0089]FIG. 13B illustrates, in flow diagram form, various hash valueembodiments. In FIG. 13B, the player terminal 300 transmits both thehashed player random number, Hash(M_(p)) (13A30), and the player randomnumber, M_(p) (13A40), to the game server 200. The game server 200transmits to the player terminal 300 the hashed game server randomnumber, Hash(M₁) (13A20), and the game server random number, M₁ (13A10).

[0090] In one or more embodiments employing a hash value operation, theplayer terminal 300 generates and transmits a hash value of its randomnumber as described above. However, in one or more alternativeembodiments, the hash value of a random number may be generated by gameserver 200, in which case the corresponding procedures of the gameserver 200 and player terminal 300 are switched.

[0091] The various embodiments providing for a hash value describedabove might not allow a player to determine whether a game server hasgenerated only one random number. The game server, for example, maydiscover two or more numbers with identical hash values, and transmitthe hash value to the player terminal. When the game server laterreceives the player number, the game server may determine which of thetwo or more numbers with identical hash values to use in the combinationprotocol (e.g., the number that will provide a result value and/or gameresult most favorable to the game server). The game server thentransmits the chosen number to the player terminal. Since the chosennumber hashes to the hash value sent earlier to the player terminal, theplayer may not suspect that he has been cheated.

[0092] To make the above-described method of cheating more difficult,high quality hash algorithms may be required. As will be understood bythose having ordinary skill in the art, a high quality hash algorithmmakes it computationally infeasible, given only a particular value, V,to generate any number, N, that hashes to V. One criterion of a goodhash function is that the hash value be of a particular minimum length.For example, if a hash value is a binary sequence of length 10, then thegame server would need hash at most 2¹⁰+1, or 1025, different numbersbefore finding two numbers with identical hash values. For most hashingalgorithms, a modern computer could very quickly run the algorithm 1025times, thereby rendering the algorithm ineffective. Therefore, hashvalues preferably should be of such length that it would becomputationally infeasible to test enough numbers so as to find twonumbers whose hash values are identical.

[0093] In one or more embodiments, player terminal 300 and game server200 simultaneously exchange random numbers, eliminating the need for anycoding or hashing to ensure the independence of the generation of therandom numbers.

[0094]FIG. 14 illustrates a procedure for this embodiment. In FIG. 14,player terminal 300 has already transmitted player selection data asdescribed above. At step 1400, player terminal 300 generates a playerrandom number, then stores it in player random number database 390 atstep 1410. At step 1420, game server 200 generates a game server randomnumber and, at step 1430, stores it in game server random numberdatabase 292. At step 1440, the player random number and the game serverrandom number are simultaneously posted to an electronic bulletin board.In one or more embodiments, this is accomplished by setting a time atwhich the random numbers are to be posted. For example, both partiesagree to post the random numbers at 3:00 PM, and incorporate this timeinto their respective communication software. At 3:00 PM, thecommunications software (not shown separately) automatically posts therandom numbers. To deter cheating, the operating system of theelectronic bulletin board may be configured to void any random numbernot posted within a desired period of time (e.g., one thousandth of asecond, one tenth of a second) from the agreed-upon posting time. Thistime requirement is preferably so small as to make the reversecalculations using a combination protocol computationally infeasible.

[0095] In one or more embodiments, neither party's number is readable bythe other party until after each party has posted its number, forexample, to an electronic bulletin board. Therefore, even if the playerposts his number first, for example, the game server cannot view thenumber, and cannot use the player number to generate a desired gameserver number. Accordingly, the above-described time period for postingmay be unnecessary to deter cheating. Of course, a time requirement forposting may be still be preferred in order to ensure a reasonable rateof play for various games. For example, the game server and the playerterminal may be required to post their respective numbers at any timebetween 3:00 PM and 3:01 PM. The parties' numbers may be made accessibleas soon as both parties have posted, or at any time thereafter. In someembodiments, the game server and the player terminal are thus able toreceive the other party's posted number at substantially the same time.Of course, the parties need not actually access each other's postednumber at the same time.

[0096] Once the player random number and the game server random numberhave been posted, a game result may be generated, according to variousembodiments of the present invention described herein.

[0097] Various methods and systems described herein may be applied togames that are primarily based on chance, such as roulette or craps, andalso to games that may be based primarily on player skill but also havean element of randomness. For example, Scrabble™ is a widely-playedboard game whose object is to assemble letters into words in such a wayas to accumulate more points than your opponent. A good Scrabble™ playertypically has a large vocabulary and an ability to spot patterns in arandom arrangement of letters. Scrabble™ is played in competitions, andthere are clear gradations in skill levels. However, there is somerandomness in Scrabble™. For example, a player receives letters tocomplete a group or “hand” of letters from which he can form words; theplayer typically selects or receives the letters at random. Accordingly,various processes and systems described herein could be used to assure aplayer (and/or a game server) that the process of letter selection isfair.

[0098] For example, in one or more embodiments, each available outcome(e.g., letter selection in Scrabble™) may be mapped to a respectiveresult value, in a manner similar to that described above with respectto a game of roulette. For example, the available letters may bearranged in a predefined order (e.g., alphabetical, by point value), ormay be sequenced at random. The position of a letter in the sequence maythen correspond to a particular result value. A player and a game servermight each select a random integer in the range of 1 to the number ofavailable letters, inclusively. According to an exemplary combinationprotocol, the player number and the game server number are added, andthe result taken modulo the number of letters remaining. One is added tothat result to obtain a result value. The result value is then used toselect the letter with the position in the sequence that corresponds tothe result value. For example, a result value of 8 would select theeighth letter in the sequence of available letters.

[0099] Bridge is a card game in which two teams of two compete to eitherobtain a predicted number of card tricks, or to prevent the other teamfrom doing so. In Bridge, the conduct of the auction and the play phasesof the game may require tremendous skill. However, the initial dealingof the hands, as in various other card games, involves chance, as cardsare typically shuffled before being dealt. Accordingly, various methodsand systems described herein may apply to the dealing of cards in abridge game.

[0100] In one or more embodiments of the present invention, the cardsstart out in a predetermined order. Each team then submits a randominteger in the range of 1 to 52. The integers are added, the resulttaken modulo 52, and then one is added to determine a result value. Theresult value indicates the position of the card in the initial orderingwith which the first card in the initial ordering should be swapped.Then each team submits another random integer in the range of 1 to 52.The integers are added, the result taken modulo 52, and then one isadded. The resulting number indicates the position of the card in thecurrent ordering with which the second card in the current orderingshould be swapped. The process continues for a total of 52 times, sothat for each possible card position, a card in that position is swappedwith another random card. That way, once each team has submitted 52random integers in the range of 1 to 52, inclusively, the deck has beenshuffled, and play can proceed.

[0101] Another game involving predominant skill, but some randomness, isa word game involving the placement of letters into a five by five grid.In this game, players receive 25 random letters, one at a time, and mustplace the letters within the five by five grid. At the end of the game,a player's point total is based on the number of rows and columns inwhich the player has spelled a word, and the length of the longest wordin each row and column. A skilled player may have a large vocabulary anda good feel for where letters are most likely to occur in words.However, there is an element of chance in the game in that a playercannot know in advance what letters he is to receive. Therefore, themethods of this invention can be used to assure a player that hereceives letters fairly, and doesn't purposely receive, for example,letters that would make it impossible for him to complete any words. Inone or more embodiments, the player terminal and the game server mighteach generate random numbers in the range of 1 to 26. The combinationprotocol then adds the numbers, takes the result modulo 26, and addsone. The result value is then used to select the letter with thecorresponding position in the alphabet.

[0102] Various embodiments described herein relate to protocols in whichone player interacts with game server 200. Multiple players could easilybe handled by treating each player individually, with players receivingindividual game results. Five roulette players, for example, could eachsubmit player selection data and receive a game result based on adifferent result value. Alternatively, players could combine theirplayer random numbers and receive a game result based on a singlecommunal result value. In this way, game server 200 may more closelyparallel a physical casino in which a group of players face wins orlosses based on the same spin of the wheel.

[0103] In various embodiments involving multiple players, each playergenerates selection data describing the type of wager that they want tomake. Game server 200 then generates a game server random number andencodes it using cryptographic processor 210. Each player terminal 300generates a player random number and encodes it with its respectivecryptographic processor 310. Each player terminal 300 then transmits itsencoded player random number to game server 200. Once game server 200has collected all encoded player random numbers, it transmits theencoded game server random number to each player terminal 300. Afterreceiving the encoded game server random number, each player terminal300 transmits its player decoding key to game server 200. Game server200 decodes each encoded player random number and uses them to generatea game result using the combination protocol from combination protocoldatabase 298, which may store different protocols for various numbers ofplayers, up to the maximum number of players allowed in a game. The gameresult is transmitted to each player terminal 300. Players can verifythe result value by exchanging decoded player random numbers with eachother and comparing them with the game server random number afterdecoding it with a game server decoding key.

[0104] In one or more embodiments, each player terminal 300 generatesplayer selection data and a player random number. The first playerencodes his player random number and transmits it to the second player.The second player concatenates his random number with the encoded randomnumber from the first player, and encodes both numbers before sendingthem to the third player. This process continues for each of theplayers. The last player sends the combined player random number to gameserver 200. Game server 200 creates a game server random number, encodesit, then transmits it to each player. After receiving the game serverencoded random number, each player terminal 300 sends its playerdecoding key to game server 200. Cryptographic processor 210 of gameserver 200 decodes the combined player random number using thesedecoding keys, forms a result value, and produces a game result for eachplayer.

[0105] As will be understood by those having ordinary skill in the art,instead of, or in addition to, the mutual encoding described above, hashalgorithms, single encoding, and simultaneous exchange proceduresconsistent with those described above may be used to facilitate theinteraction of multiple players.

[0106] Outcomes for gambling games are determined by either a singleevent or a multiple event. Roulette and slots are good examples ofsingle event games as a single outcome determines the game result. Onespin of the roulette wheel completely resolves all bets placed on thatspin. The result of a slot machine wager requires a single handle pullto determine whether the player wins or loses. In these single eventgames, a result value is easily compared to player selection data todetermine a game result.

[0107] In multiple event games, however, a game result may be based onmultiple result values. Blackjack is one example of a multiple eventgame. Whether a player wins a hand depends on the player's cards and thedealer's cards. Accordingly, in one or more embodiments of theinvention, a result value represents the complete sequence of fifty-twocards. Once the card sequence is defined based on the player randomnumber and the game server random number, the cards can be dealt.

[0108] For example, after generating an encoded player random number andtransmitting it to game server 200, player terminal 300 receives theencoded game server random number. Player terminal 300 then transmits adecoding key to game server 200 which generates the result valuerepresenting the complete sequence of cards in the deck. Before sendinga game server decoding key to player terminal 300, game server 200 sendsthe player card values representing a hand of cards dealt from thesequence of cards generated by the result value. If he desires, theplayer then elects to draw additional cards for his blackjack hand,again, from the defined sequence of cards. Once the hand is selected,game server 200 transmits a game server decoding key to player terminal300. It is important that the player not receive this key before makinghis selection to draw additional cards, since decoding the game serverencoded random number would allow the payer to know the completesequence of cards.

[0109] Another method for handling multiple event games, such asblackjack games, is to generate a result value for each event (e.g.,each card dealt, each hand dealt). In a blackjack example, after makinghis bet (by establishing player selection data) the player generates aseries of player random numbers, exchanging them with game server 200for each card required in the hand. The game result might thereforerequire seven or eight result values, each one created according to oneor more of the various described procedures of the present invention.

[0110] Accordingly, it will be understood by those having ordinary skillin the art that a single result value may correspond to one or moreevents. For example, as described herein, one result value may be usedto determine only a corresponding single card, or a single result of aslot machine spin. As also described herein, one result value may alsocorrespond to a series, set, or sequence of events, such as a pluralityof cards (e.g., a deal of cards, a hand of cards, or a deck of cards). Aparticular game, system, or application need not use all determinedresult values in any one way. Accordingly, a particular game, system, orapplication may use a first result value to determine a single event anda second result value to determine multiple events. Specifically, itwill be understood that any particular determined result value may beused to determine a corresponding single event or corresponding multipleevents, as considered practicable for the particular game, system orapplication.

[0111] In certain embodiments of the present invention, authenticationof authorship of the player selection data and player random numberinvolves checking an attached ID or name and comparing it with thosestored in player database 255. In an alternative embodiment,cryptographic protocols are added to the authentication process. Theseprotocols enhance the ability to authenticate the sender of a messageand serve to verify the integrity of the communication itself, provingthat it has not been altered during transmission. Encryption can alsoprevent eavesdroppers from learning the contents of the communication.Such techniques shall be referred to generally as cryptographicassurance methods and include the use of both symmetric and asymmetrickeys as well as digital signatures and hash algorithms.

[0112] The practice of using cryptographic protocols to ensure theauthenticity of senders as well as the integrity of communications iswell known in the art and need not be described here in detail. Anyconventional cryptographic protocols such as those described in BruceSchneier, Applied Cryptography: Protocols, Algorithms, and Source Codein C, (2^(nd) ed., John Wiley & Sons, Inc., 1996), could be used inaccordance with the present invention and would be executed bycryptographic processor 210.

[0113]FIG. 15 illustrates a symmetric key embodiment in which playerterminal 300 and game server 200 share a key. Thus, both encryption anddecryption of the player selection data and player random number (alsoreferred to separately or together as a player communication) areperformed with the same key. This encryption may be implemented with analgorithm such as DES (U.S. Government standard, specified in FIPS PUB46), or with any of several algorithms known in the art such as AES,IDEA, Blowfish, RC4, RC2, SAFER, etc.

[0114] Initially, a player encrypts his communication with his assignedsymmetric key at step 1500, using cryptographic processor 310 of playerterminal 300. The key may be stored in encoding key database 375 orotherwise stored or memorized by the player. The player communication isthen transmitted to cryptographic processor 210 of game server 200 atstep 1510. Cryptographic processor 210 extracts the player ID from theplayer communication (step 1520), looks up the symmetric key of theplayer in player database 255 (step 1530), and decrypts the playercommunication with this key (step 1540). Game server encoding keydatabase 294 contains algorithms and keys for encrypting, decrypting,and/or authenticating communications. At step 1550, the cryptographicprocessor 210 determines if the resulting communication is intelligible.If so, then the communication must have been encrypted by the same key,authenticating that the player must have indeed been the author of themessage. It will be understood that these cryptographic techniques areemployed to protect the security of the communications, in addition tothe appropriate random number encryption technique described above.

[0115] This procedure makes it difficult for an unauthorized player torepresent himself as a legitimate player. Without cryptographicprocedures, an unauthorized player who obtained a sample communicationfrom a legitimate player might be able to extract the player ID and thenattach this ID number to unauthorized communications. When playercommunications are encrypted with a symmetric key, however, anunauthorized player obtaining a sample player communication onlydiscovers the player's ID number, not the symmetric key. Without thiskey, the unauthorized player cannot create a player communication thatwill fool game server 200, since he cannot encrypt his communication inthe same way that the authorized player could. The symmetric keyprotocol also ensures that the player communication has not beentampered with during transmission, since alteration of the communicationrequires knowledge of the symmetric key. An encrypted playercommunication also provides the player with more anonymity.

[0116]FIG. 16 illustrates an asymmetric key protocol in which a playercommunication is encrypted with a private key and decrypted with apublic key. Two such algorithms for asymmetric key protocols are the RSAalgorithm and the Digital Signature Algorithm (“DSA”). At step 1600,player terminal 300 encrypts the player communication with the player'sprivate key using cryptographic processor 310. Player terminal, 300 thentransmits the player communication to game server 200 at step 1610.Cryptographic processor 210 at game server 200 then extracts the playerID at step 1620, looks up the players associated public key in playerdatabase 255 at step 1630, and decrypts the communication with thispublic key at step 1640. As before, if the player communication isintelligible then game server 200 has authenticated the player at step1650. Again, unauthorized players obtaining the player communicationbefore it is received by game server 200 are not able to undetectablyalter it since they do not know the private key of the player.Unauthorized players might, however, be able to read the message if theymanaged to obtain the public key of the player. Communication secrecy isobtained if the player encrypts the player communication with his publickey, requiring the unauthorized player to know the player's private keyto view the player communication.

[0117]FIG. 17 shows a cryptographic technique using digital signaturesto provide authentication and message integrity. One such algorithm isDSA. As in the asymmetric protocol described above, each player has anassociated public and private key. The player signs his communicationwith his private key at step 1700 with cryptographic processor 310 andtransmits it to game server 200 at step 1710. At game server 200,cryptographic processor 210 extracts the player ID at step 1720 andlooks up the player's public key at step 1730, verifying the signatureusing the communication and the public key of the player at step 1740.If the communication is intelligible, then game server 200 accepts thecommunication as authentic at step 1750.

[0118] Referring now to FIG. 18, there is illustrated a cryptographictechnique using message authentication codes for verifying theauthenticity and integrity of a player communication. In the hashprotocol of the present invention, player terminal 300 and game server200 share a symmetric key, which the player includes in a hash of thecommunication at step 1800. In the hash protocol, a one-way function isapplied to the digital representation of the communication. Any of theMAC algorithms, such as RIPEMAC, IBC-Hash, CBC-MAC, or the like, may beapplied in this application. After transmitting the communication togame server 200 at step 1810, cryptographic processor 210 of game server200 extracts player ID from the player communication at step 1820. Thencryptographic processor 210 looks up the player's symmetric key at step1830 and hashes the communication with the symmetric key at step 1840,comparing the resulting hash value with the hash value attached to thecommunication. If the values match at step 1850, the integrity of thecommunication is verified along with the authenticity of the player.

[0119] Although cryptographic techniques can provide greater confidencein the authenticity of player communications, they are useless if theplayers' cryptographic keys are compromised. An unauthorized player whoobtains the symmetric key of another player is indistinguishable fromthat player in the eyes of game server 200. There is no way to knowwhether the player was the true author of the communication, or anunauthorized player with the right cryptographic keys. In one or moreembodiments, biometric device 355 (FIG. 3) such as a fingerprint reader,voice recognition system, retinal scanner, or the like help to solvethis problem. A biometric device incorporates a physical attribute ofthe player into a communication, which is then compared with the valuestored in player database 255 at game server 200.

[0120] Fingerprint verification, for example, may be executed before thecreation of a communication, during the generation of a communication inresponse to prompts from game server 200, at some predetermined orrandom time, or continuously by incorporating the scanning lens intoplayer terminal 300 and requiring the player to maintain a finger on thescanning lens at all times for continuous verification while thecommunication is generated.

[0121] An example of such a biometric device is the FingerLoc™ AF-S2™fingerprint identification system available from AuthenTec, Inc. TheAF-S2™ utilizes a sensor matrix, consisting of 16,384 individualelements arranged in a 128 by 128 grid. When a player places his fingeron the grid, an electromagnetic signal is generated by a ringsurrounding the grid. The resulting electromagnetic field variesaccording to the ridges and valleys of the player's fingerprint. Eachelement of the grid then acts as an antenna, picking up the localelectromagnetic signal. The elements can distinguish fine variations inthe electromagnetic field, and use these variations to generate adigital fingerprint image. The digitized image is then stored in memory.Each live-scan fingerprint is compared against the previouslyenrolled/stored template, stored in data storage device 360. If theprints do not match, the cryptographic algorithms executed bycryptographic processor 310 may prevent the player from generating acommunication.

[0122] In a voice verification embodiment, the player's voice is used toverify his identity. This embodiment has the advantage of not requiringthe use of any specialized hardware since it can be implemented over astandard phone connection. The player's identity is verified at gameserver 200. The process of obtaining a voice-print and subsequentlyusing it to verify a person's identity is well-known in the art, andtherefore need not be described in detail. Conventional speakeridentification software samples the player's voice. This sample isstored at game server 200 in player database 255. Each time the playerwants to transmit a communication to game server 200, he is required tocall game server 200 and speak into the phone at the prompt for a voicesample. If this sample matches that stored in player database 255, theplayer is provided a password which is incorporated into the digitalsignature appended to his communication. Any communication receivedwithout an appropriate voice match password is not accepted. Thevoice-print may also be stored in a database within data storage device360 of player terminal 300, to verify the player's identity locallyprior to allowing his communication to be created.

[0123] As mentioned previously, the present invention allows for theanonymity of players. Such anonymity is accomplished by eliminating allreferences to the names of the players for all communications. A player,for example, would include his ID in the player selection data, ratherthan his name, preventing eavesdroppers from discovering the player'sidentity. To prevent detection of a players ID stored in player database255, the ID numbers are preferably encrypted with the public key of gameserver 200.

[0124] As an additional protection of identity, the player maycommunicate with game server 200 through conventional anonymousremailers found on the Internet.

[0125] While the invention can be implemented without provisions forpayment features, there are many methods by which the providers of theforegoing systems could derive a revenue stream. In one or moreembodiments, a flat fee is charged for every set of player selectiondata submitted. In other embodiments, flat fees would cover any numberof sets of player selection data over a given period of time, allowingplayers to subscribe to the service much as they would subscribe to anewspaper. In another embodiment, advertisers pay to have messageslisted along with the Web pages for the player selection data,supplementing the costs of operating the system.

[0126] In some embodiments of the present invention, the combinationprotocol may transform the player random number and the game serverrandom number into multiple result values. For example, the multipleresult values could represent ten different spins of a roulette wheel,five different rolls of the dice in craps, or twelve different cardsdrawn in video poker. With multiple result values being generated basedon a single pair of random numbers, the player terminal and the gameserver would have to generate fewer random numbers, and would have toperform fewer encryption and decryption operations, thus speeding up theplay of the game.

[0127] In a roulette game, for example, the combination protocol maytransform the player random number and the game server random numberinto multiple result values corresponding to multiple spins. In twotypical games of roulette, there are 38*38, or 1444, possible sequencesof two outcomes (e.g., “1” and “9”; “24” and “24”; or “00” and “12”).Therefore, in one exemplary combination protocol, the player randomnumber and the game server random number might each be a number between1 and 1444, inclusive. According to the combination protocol, the tworandom numbers are then added, modulo 1444, to yield a number between 0and 1443, inclusive. This number is then divided by 38 in order to yielda quotient and a remainder. Both the quotient and the remainder will benumbers between 0 and 37, inclusively. The quotient may thus serve as afirst result value, and the remainder may serve as a second resultvalue. Each result value may be mapped to respective individualoutcomes, each individual outcome representing, for example, one spin ofa roulette wheel.

[0128] Although the exemplary combination protocol was described abovewith respect to two result values for a roulette game, other combinationprotocols useful for transforming a player random number and a gameserver random number into one or more result values will be obvious tothose having ordinary skill in the art. Similarly, combination protocolsuseful for various different types of games will be obvious to thosehaving ordinary skill in the art.

[0129] In some embodiments of the present invention in which more thanone result value is obtained from a game server number and a playernumber, the player must place wagers on all result values to be obtainedfrom a combination protocol before obtaining a decoding key from thegame server. Otherwise, the player would be able to predict futureresult values by using the combination protocol applied to the playerrandom number and the game server random number. The player could thenmake wagers only when future result values would be favorable to theplayer.

[0130] In some embodiments, the player, the player terminal, and/or thegame server may establish rules for placing wagers on the multipleresult values to be obtained from a combination protocol (and/or on thecorresponding game results). Such rules could be stored, for example, inplayer database 255. A rule might specify, for example, that if theplayer wins on a first result value, he is to double his wager for thenext result value. Another rule might specify that a player is tocontinue placing wagers on successive result values until his net lossexceeds ten tokens. Once rules for placing wagers have been established,and the player has committed to following such rules, then it no longermatters whether or not the player can anticipate future result valuesthrough the use of the game server decoding key. Even if the playerknows that future result values will be unfavorable, he is still boundto follow the specified rules for placing wagers.

[0131] Even if a first party may be confident that a second party hasgenerated its random number independently of the first party's number,the first party may not be sure that the other party has generated onlyone number.

[0132] For example, the game server may attempt to cheat by generatingtwo or more game server numbers, such that each can be encoded to yieldthe same result. Once the game server knows the player random number,the game server can determine which of the two or more game servernumbers to use in the combination protocol in order to achieve a desiredgame result. For example, after the game server receives the playerdecoding key, the game server can decode an encoded player randomnumber. Alternatively, an unencoded player random number may have beenreceived. Based on the player random number, the game server thentransmits to the player terminal the game server decoding keycorresponding to the chosen random number. The game server then uses thecombination protocol, the player random number, and the chosen gameserver random number to generate the game result.

[0133] For example, a game server may use the following procedure togenerate multiple numbers whose encoded values are identical. First, thegame server generates multiple pairs of keys, E_(K) and D_(K),representing keys in an asymmetric key algorithm. In each pair, E_(K) isused in combination with an encryption algorithm to generate an encodedversion of a number, M_(K). The encoded number is denoted E_(K)(M_(K)).Given E_(K)(M_(K)), M_(K) can be determined by employing the key D_(K)in a decrypting algorithm. Thus, D_(K)(E_(K)(M_(K)))=M_(K).

[0134] At step 1952 in FIG. 19A, the game server generates multipledecoding keys. The generation of the game server encoding keys is notalways necessary. Once the game server has generated the multiple pairsof keys, the game server, at step 1954, chooses a number, M₁. The numberM₁ may be generated randomly or may be chosen by the game server in anyother fashion. The game server then generates M₂ according to thefollowing formula: M₂=D₂(E₁(M₁)). Similarly, M₃=D₃(E₁(M₁)), andM_(K)=D_(K)(E₁(M₁)).

[0135] The game server initially transmits to the player terminalE₁(M₁), (step 1956). At step 1958, the game server receives from theplayer the encoded player random number, and at step 1960, the gameserver receives from the player the player decoding key, which allowsthe game server to view the player random number (step 1962). At step1964, the game server may test the combination protocol on the player'snumber in combination with each of M₁, M₂, . . . M_(n). The game serverthen chooses a number, M_(K), from the set of M₁, M₂, . . . M_(n), thatyields the result value that is most desirable for the game server. Atstep 1966, the game server then transmits the corresponding decodingkey, D_(K), to the player terminal. Finally, at step 1968, the gameserver generates the game result based on the player random number andthe chosen game server number.

[0136] Note that in the above procedure, M₁ need not be chosen. Rather,E₁(M₁) may be chosen, and M₁ may be derived by M₁=D₁(E₁(M₁)). Also notethat the encrypting keys, E₁ . . . E_(n), need not necessarily ever begenerated.

[0137]FIG. 19B illustrates various embodiments of the present inventionin flow diagram form. In FIG. 19B, game server 190 initially generatesthree game server decoding keys: D₁, D₂, and D₃ (1970, 1972, and 1974,respectively). Game server 190 ultimately transmits to the playerterminal 300 an encoded version of a game server number, E₁(M₁) (1976),and only one of the three game server decoding keys: D₂ (1972). Theplayer terminal transmits to the game server the encoded player randomnumber, E_(p)(M_(p)) (1978), and a single decoding key D_(p) (1980).

[0138] The exemplary attempt to cheat described above may be overcome invarious ways. According to some embodiments of the present invention,when the game server, for example, transmits E₁(M₁) to the playerterminal, the game server may also be required to transmit the encodingkey, E₁, to the player terminal, before the game server can know theplayer random number (e.g., before receiving an unencoded player randomnumber, or before receiving a decoding key for an encoded player numberreceived by the game server). For example, the game server may berequired to transmit the encoding key, E₁, to the player terminal beforetransmitting the encoded game server number, after transmitting theencoded game server number, or along with the encoded game servernumber.

[0139] If the game server later transmits to the player terminal adecoding key, say D₂, that does not correspond to the encoding key, E₁,then the player will be able to determine whether he has been cheated.To determine whether the encoding key E₁ corresponds to the decoding keyD₂, the player may, for example, encode a test number, M, with encodingkey E₁, and then decode the result with decoding key D₂. In thisexample, the decoded result will not be the same as the original number,M. In other words, D₂(E₁(M)) does not equal M. Therefore, by having thegame server transmit the encoding key E₁ to the player terminal beforethe game server knows the player random number, the game server will bemotivated to transmit the proper decoding key, D₁, to the playerterminal.

[0140] One or more embodiments of the present invention require anyrandom numbers generated to be combined in some fashion with at leastone known character, before encoding the combination. For example,suppose the game server generates a random number, 1297. The charactersequence “bluesky” is then appended to the end of the number, yieldingthe combination, “1297bluesky”. The full character sequence,“1297bluesky”, is then encoded with key E₁ and sent to the playerterminal. Now suppose the game server receives the player's encodednumber and decoding key, and decides to use a number other than 1297 inthe combination protocol. So the game server might attempt to use adecoding key, D₂, that does not match the encoding key, E₁.D₂(E₁(1297bluesky)), however, is unlikely to yield a character sequenceending in “bluesky”. That is, D₂(E₁(1297bluesky)) does not equal“xxxxbluesky”, where “xxxx” represents any set of characters. If thegame server sends to the player terminal the decoding key, D₂, and theplayer decodes the game server's first transmission, E₁(1297bluesky),and finds that the result does not end with “bluesky”, then the playerwill realize he has been cheated. To cheat, the game server mustdetermine a new decoding key that does yield a result of the form“xxxxbluesky”. However, such a task may be computationally unfeasible.

[0141] Of course, in the above example, “bluesky” could be appended tothe front end of the number. In some embodiments, at least one characteris appended to one end of the number and at least one character isappended to the other end of the number.

[0142] Although any set of one or more characters may be used incombination with a random number, certain character sequences may beparticularly convenient to use in combination with random numbers. Someof these character sequences may include, without limitation, a player'sname, a player's casino card number, a date, or a time. If, for example,it is always a player's name that is appended to the game server randomnumber, then the player does not have to find out at the beginning of agaming session what appended character sequence to look for.

[0143] In one or more embodiments of the present invention, the set ofsignals that can be transmitted between the game server and the playerterminal is limited. The set of signals may be limited to only onesignal (e.g., “5”), to a plurality of signals (e.g., “5” and “10”), to arange of signals (e.g., 2 to 12), to particular types of signals (e.g.,numbers, random numbers, alphanumeric characters, audio signals, videosignals, algorithms), and may be limited by any combination of suchlimitations. Many other types of limitations will be known to those ofskill in the art.

[0144] In one example, the player and the game server may be involved ina game of craps. To represent every possible roll of two dice, the gameserver and the player need only exchange integer random numbers in therange of 1 to 36, inclusively (or in the range 2 to 12, inclusive, torepresent just the sum of the die faces). At the same time, the gameserver and the player terminal employ an encoding algorithm that iscapable of handling inputs greater than 36. Therefore, if a game serverencodes the number 24, for example, with the encoding key E₁, but laterdecodes the result with a decoding key, D₂, then the resulting number ismost likely to be out of the range 1 to 36. For example, D₂(E₁(24))might equal 153982. Therefore, the game server would be forced to searchfor a new decoding key that yielded a result between 1 and 36, a taskthat may be computationally unfeasible.

[0145] Those having ordinary skill in the art will understand that thevarious techniques described herein for circumventing or discouragingcheating (e.g., cheating in which one party derives more than one numberthat may be encoded to derive the same value), may be appliedalternatively, or in any combination. For example, the range of randomnumbers may be restricted to a range, and the game server 200 may berequired to transmit an encoding key to player terminal 300. Further,while such embodiments are often described herein as useful forpreventing cheating by a game server 200, those having ordinary skill inthe art will understand that corresponding techniques may be used,alternatively or in addition, by a game server (or by any party) toprevent cheating by a player (or by any other party).

[0146] In various embodiments of the present invention, a third partymay be involved as an intermediary between the player terminal and thegame server. For example, in one or more embodiments of the presentinvention each party submits its number, unencoded, to a third party.Once the third party receives both numbers, the third party transmitsthem to the player terminal and to the game server. As an extra measureof security, the player terminal and the game server may first encodetheir numbers before transmitting them to the third party. The thirdparty may then transmit the encoded numbers to the player terminal andto the game server. The player terminal and the game server may thensend decoding keys to the third party. Of course, a decoding key may betransmitted to the third party before the encoded random number istransmitted to the third party, or may be transmitted to the third partyalong with the encoded random number. After receiving the decoding keys,the third party may then transmit the decoding keys to the playerterminal and to the game server. Although, the above example describesmutual encoding of numbers, those having ordinary skill in the art willunderstand that a third party may similarly be involved as anintermediary in various processes involving single encoding, hashvalues, etc.

[0147] In one or more embodiments of the present invention, the thirdparty first transmits to the player terminal and to the game server anencoding key. The player terminal and the game server may or may notreceive the same encoding key. The player terminal uses the encoding keyit received from the third party to encode its random number, and maythen transmit its encoded number to the game server, either directly orthrough the third party. Similarly, the game server uses the encodingkey it received from the third party to encode its random number, andmay then transmit its encoded number to the player terminal, eitherdirectly or through the third party. The third party may then transmitdecoding keys to the player terminal and to the game server. The playerterminal and the game server may or may not receive the same decodingkey. Each party is then able to decode the other's random number, and togenerate a game result using the combination protocol. Advantageously,the game server is not able to cheat by choosing which of severalpossible decoding keys to use. Instead, the game server must use thedecoding key supplied by the third party.

[0148] In one or more embodiments, the player terminal and the gameserver each transmit their respective numbers, unencoded, to the thirdparty. The third party then uses its own encoding key(s) to encodeeither or both of the numbers. The third party then transmits theplayer's number (whether unencoded or encoded) to the game server, andthe game server's number (whether unencoded or encoded) to the player.If the player's number is encoded by the third party, the third partyalso transmits the decoding key for the player's number to the gameserver. Similarly, if the game server's number is encoded by the thirdparty, the third party also transmits the decoding key for the gameserver's number to the player terminal. The third party may transmit adecoding key after transmitting an encoded number, before transmittingthe encoded number, or along with the encoded number.

[0149] As described above, various embodiments of the present inventionprovide for requiring one or both of the parties to transmit itsencoding key to the other party along with its encoded random number, inorder to prevent cheating in which once the other party's number isknown, a party can determine which of two or more generated numbers touse in the combination protocol in order to achieve a desired gameresult, and may transmit the corresponding decoding key.

[0150] In order to circumvent such cheating, according to one or moreembodiments of the present invention, one or both parties may berequired to send their encoding and/or decoding keys to a third partybefore knowing the other party's number. For example, the game servermay be required to send its decoding key to the third party beforereceiving a decoded player number. Of course, the game server mayalternatively send the decoding key after receiving an encoded playernumber, but before receiving the player decoding key (i.e., before itcan decode the player number). As described herein with respect tovarious embodiments, one or both of the parties may also provide adecoding key to the other party. By providing encoding keys and/ordecoding keys to the third party, however, if the player questions thedecoding key received from the game server, for example, then the playermay check with the third party and verify that the decoding key receivedfrom the game server was the same decoding key that was received by thethird party before the game server knew the decoded player number. Insome embodiments, the player and the game server may receive eachother's decoding keys directly from the third party. The player and gameserver are thus prevented from choosing amongst multiple decoding keysto send to the other party.

[0151] A third party or intermediary, as described herein, may compriseone or more third parties or intermediaries. Where more than one thirdparty is being used, each may function independently of any others. Forexample, to exchange numbers, a player terminal may transmit the playerrandom number to one third party, who transmits the number to the gameserver. The game server may transmit the game server random number toanother third party, who transmits the number to the player terminal. Insome embodiments involving multiple third parties, the player terminaland/or game server may transmit to, and/or receive information from,more than one third party. For example, a player terminal may transmitthe player number to one third party, who transmits the number to thegame server. The player terminal may also transmit a player decoding keyto another third party, who transmits the decoding key to the gameserver. Various embodiments of the present invention are describedherein as involving an exchange of numbers between two parties, forexample, a game server and a player terminal. However, a player terminaland a game server could just as easily exchange many different types ofinformation, including, without limitation, numbers, letters, symbols,pictures, audio signals, video signals, algorithms, or any combinationthereof. For example, a particular game of chance may have two possibleoutcomes, denoted “outcome 1” and “outcome 2”. The player terminal andthe game server each provide either the letter “a” or the letter “b”.According to an exemplary combination protocol, if both the letters arethe same, then outcome 1 occurs. If both letters are different, thenoutcome 2 occurs.

[0152] In one or more embodiments of the present invention, one partygenerates a random number, and the other party generates a function oralgorithm. In an exemplary combination protocol, the function oralgorithm provided by a player is applied to the random number providedby a game server to generate the result value and the game result. Forexample, the game server generates a number, 4. The player terminalgenerates an algorithm that says:

[0153] 1) Multiply the game server's number by 3 to generate the numberx1

[0154] 2) Take x1 modulo 5 to generate the number x2

[0155] 3) Add 1 to x2 to generate the result value

[0156] Applying the player algorithm to the game server number, 4,yields: x1=4*3=12; x2=12 modulo 5=2; and a result value of 1+2=3. Withthe above exemplary algorithm, any integer generated by the game serverin the range 1 to 5, inclusively, is mapped to the same range in aone-to-one fashion. That is, if the game server generates the number 1,then the result value will be 4. If the game server generates the number2, the result value will be 2. If the game server generates the numbers3, 4, or 5, then the result values will be 5, 3, or 1, respectively.Thus, assuming valid result values must fall in the range of 1 to 5, theabove algorithm is fair in that it allows any result value in the validrange of result values to occur. Furthermore, if the game server numberis generated randomly such that each integer between 1 and 5,inclusively, is equally likely to occur, then all result values willalso be equally likely to occur.

[0157] In one or more embodiments of the present invention, both thegame server and the player terminal generate algorithms. As will beunderstood by those having ordinary skill in the art, two or morealgorithms may be combined in a combination protocol in a number ofways. For example, in one or more embodiments, the combination protocolspecifies an input to the game server algorithm. The input may be anumber, such as 14923. The game server algorithm then operates on theinput to produce an output. An exemplary output of the game serveralgorithm might be the number 2094. According to the exemplarycombination protocol, the output of the game server algorithm is thenused as an input (or as one of multiple inputs) to the player algorithm.The player algorithm then operates on the output of the game serveralgorithm to produce its own output, which is the result value.

[0158] In the above example, as will be understood by those havingordinary skill in the art, the player algorithm could have been runbefore the game server algorithm (e.g., the combination protocol couldhave specified a first input for the player algorithm, and the output ofthe player algorithm could have been an input for the game serveralgorithm). In some embodiments, rather than having the combinationprotocol specify the input to the first algorithm, the player terminalor the game server might specify the input to the first algorithm. Insome embodiments, the game server and the player terminal specifymultiple algorithms. The algorithms may then be chained together in anyorder, with the output of one serving as the input for the next. Ofcourse, as is well-known in the art, many other ways of combiningalgorithms are possible.

[0159] There are a number of ways in which a function or an algorithmmay be represented for the purposes of transmission between the gameserver and the player terminal. As is well-known, a function may berepresented by a set of numerals, letters, and/or symbols composing amathematical formula. For example, f(x)=(3x mod 5)+1. In this example, xrepresents the input to the function. The input x may be generatedrandomly (e.g., by the game server). The output of the player algorithmis represented by f(x), and the right side of the exemplary formulashows how to generate f(x) through the operations of multiplication,modulo division, and addition.

[0160] In one or more embodiments, a function or algorithm isrepresented by computer program code. The code may be in any language,such as C, Java, Basic, or Fortran. The code may be written in compiledor uncompiled form. An exemplary line of code might read,“result_value=(3*input) % 5+1;”. This line of code, written in C,multiplies the “input” variable by 3, takes the result modulo 5, andthen adds one to generate the “result_value”. There are many otherwell-known ways of representing a function or an algorithm usingcomputer program code.

[0161] In one or more embodiments, a function or algorithm isrepresented by a table of inputs and corresponding outputs. For example,the set of inputs might be listed as: 1, 2, 3, 4, and 5. The respectiveoutputs might be listed as: 4, 2, 5, 3, 1. Outputs may be listed in thetable, for example, adjacent to their corresponding inputs.

[0162] Various embodiments described herein with respect to the exchangeof numbers may also apply to an exchange involving at least onealgorithm or function. According to one or more embodiments of thepresent invention, once a function or algorithm has been represented(e.g., in the form of text), then the representation may be encoded. Theencoded function or algorithm is then given to the other party, and theother party's encoded number, function or algorithm is received.According to some embodiments, one or more decoding keys may also beexchanged.

[0163] In one or more embodiments of the present invention, a fulldescription or representation of an algorithm need not be transmitted tothe opposite party. Instead, only particular features or elements of analgorithm need be transmitted, where the rest of the algorithm isunderstood by both parties. For example, an algorithm may have a fixedstructure or template, but may require one or more elements be definedso that the algorithm may generate an output. In one example, analgorithm known to both parties is described by f(x)=(??x mod 5)+1,where “??” represents a multiplier value that must be defined. So, theplayer terminal, for example, might transmit to the game server thenumber, 3, whereby the game server understands that the player terminalis describing the function f(x)=(3x mod 5)+1.

[0164] Just as, in some described embodiments, the player terminaland/or game server may generate numbers randomly, in one or moreembodiments the player terminal and/or game server may generatealgorithms randomly. For example, a exemplary base algorithm may have afixed structure with an undefined multiplier, as described above. Themultiplier may be determined randomly, thereby generating the algorithmat random.

[0165] In one or more embodiments, a player terminal and/or a gameserver has multiple possible algorithms stored, for example, in amemory. The game server and/or the player may then choose one of thepre-existing algorithms at random, and transmit the algorithm to theother party.

[0166] In one or more embodiments of the present invention, the playerand/or the game server represent a function as a table. All possibleinputs are listed, for example, in one column of the table. All possibleoutputs are then ordered at random, and preferably located in anadjacent column of the table. Accordingly, any input may be referencedin the first column, and will yield a random output listed adjacently inthe second column. Outputs may or may not be listed multiple times,depending on the desired probability of occurrence of the output. As anexample, a function has five possible inputs: 1, 2, 3, 4, or 5, and fivepossible outputs, also: 1, 2, 3, 4, or 5. To create a random function,the game server lists the possible inputs in order: 1, 2, 3, 4, and 5,in a column. The game server then selects a random arrangement of theoutputs, here: 3, 5, 2, 1, 4. Then, the outputs are preferably listed ina column adjacent to the inputs. Thus, an input of 1 would yield anoutput of 3, an input of 2 would yield an output of 5, and so on.

[0167] There are many other well-known methods for generating algorithmsrandomly; others will be apparent to those having ordinary skill in theart.

[0168] Even if a party is confident that two numbers being used in acombination protocol are generated independently of one another, theparty may want to ascertain a level of fairness of the combinationprotocol itself. For example, a combination protocol being used in agame, although known to both parties, may have been generated by oneparty. Accordingly, the other party might want to verify that thecombination protocol is fair. If a party is able to determine that acombination protocol meets some criterion for fairness, that party maybe more willing to engage in a game.

[0169] One or more embodiments of the present invention provide fordetermining a level of fairness of a combination protocol. One possiblecriterion for a fair combination protocol is that it does not alloweither the player or the game server to unilaterally change theprobability of occurrence of a particular result value. For example,suppose the game server wished for a result value of 200. With a faircombination protocol, the game server should not be able to choose agame server number such that the result value of 200 is any more likelythan if the game server had chosen the game server number at random. Anexemplary fair combination protocol would receive a player number and agame server number, each an integer between 1 and 1000, inclusively. Theprotocol would then add the two integers, take the result modulo 1000,and add 1. Therefore, the result value would be an integer between 1 and1000. Suppose that, using this combination protocol, the game server andthe player terminal each chose their respective numbers at random, witheach integer between 1 and 1000, inclusively, being equally likely. Theplayer number will be denoted x_(p), and the game server random numberx_(g). The probability mass function for x_(p) is then given byp[x_(p)]=1/1000u[x_(p)−1]u[−x_(p)+1000]. Note that the square bracketsdenote a discrete function, one that is defined only over the set ofintegers. Also, u[n] is the unit step function, defined to be zero forn<0, and 1 for n>=0. The probability mass function for x_(g) is the sameas that for x_(p). The sum of the player and the game server's randomnumbers will be denoted y, where y=x_(p)+x_(g). The probability massfunction for the sum of the player number and game server number isobtained by taking the convolution of the individual probability massfunctions. Thus, $\begin{matrix}{{p\lbrack y\rbrack} = \quad {{p\left\lbrack x_{p} \right\rbrack}*{p\left\lbrack x_{g} \right\rbrack}}} \\{= \quad {\sum\limits_{k = {{- \infty}\quad \infty}}{{1/1000}{u\left\lbrack {k - 1} \right\rbrack}{u\left\lbrack {{- k} + 1000} \right\rbrack}{1/}}}} \\{\quad {1000{u\left\lbrack {y - k - 1} \right\rbrack}{u\left\lbrack {{- \left( {y - k} \right)} + 1000} \right\rbrack}}} \\{= \quad {{\left( {y - 1} \right)\left( 10^{- 6} \right){u\left\lbrack {y - 1} \right\rbrack}{u\left\lbrack {{- y} + 1001} \right\rbrack}} +}} \\{\quad {\left( {{- y} + 2001} \right)\left( 10^{- 6} \right){u\left\lbrack {y - 1002} \right\rbrack}{u\left\lbrack {{- y} + 2000} \right\rbrack}}}\end{matrix}$

[0170] Here, the symbol “*” denotes convolution. Now let z=y modulo1000. The probability mass function for z can be obtained by adding theprobability mass function for y in the range 0<=y<=999, the probabilitymass function for y in the range 1000<=y<=1999 shifted to the left by1000, and the probability mass function for y in the range 2000<=y<=2999shifted to the left by 2000. Thus, $\begin{matrix}{{p\lbrack z\rbrack} = \quad \left( {{\left( {z - 1} \right)\left( 10^{- 6} \right){u\left\lbrack {z - 1} \right\rbrack}{u\left\lbrack {{- z} + 1001} \right\rbrack}} + {\left( {{- z} + 2001} \right)\left( 10^{- 6} \right)}} \right.} \\{\quad {{{u\left\lbrack {z - 1002} \right\rbrack}{u\left\lbrack {{- z} + 2000} \right\rbrack}} + {\left( {z + 1000 - 1} \right)\left( 10^{- 6} \right)}}} \\{\quad {{{u\left\lbrack {z + 1000 - 1} \right\rbrack}{u\left\lbrack {{- \left( {z + 1000} \right)} + 1001} \right\rbrack}} + \left( {{- \left( {z + 1000} \right)} + 2001} \right)}} \\{\quad {{\left( 10^{- 6} \right){u\left\lbrack {\left( {z + 1000} \right) - 1002} \right\rbrack}{u\left\lbrack {{- \left( {z + 1000} \right)} + 2000} \right\rbrack}} +}} \\{\quad {{\left( {z + 2000 - 1} \right)\left( 10^{- 6} \right){u\left\lbrack {z + 2000 - 1} \right\rbrack}{u\left\lbrack {{- \left( {z + 2000} \right)} + 1001} \right\rbrack}} +}} \\{\quad {\left( {{- \left( {z + 2000} \right)} + 2001} \right)\left( 10^{- 6} \right){u\left\lbrack {\left( {z + 2000} \right) - 1002} \right\rbrack}}} \\{{\quad \left. {u\left\lbrack {{- \left( {z + 2000} \right)} + 2000} \right\rbrack} \right)}{u\lbrack z\rbrack}{u\left\lbrack {{- z} + 999} \right\rbrack}} \\{= \quad \left( {{\left( {z - 1} \right)\left( 10^{- 6} \right){u\left\lbrack {z - 1} \right\rbrack}{u\left\lbrack {{- z} + 1001} \right\rbrack}} + {\left( {{- z} + 2001} \right)\left( 10^{- 6} \right)}} \right.} \\{\quad {{{u\left\lbrack {z - 1002} \right\rbrack}{u\left\lbrack {{- z} + 2000} \right\rbrack}} + {\left( {z + 999} \right)\left( 10^{- 6} \right){u\left\lbrack {z + 999} \right\rbrack}}}} \\{\quad {{\left. {{u\left\lbrack {{- z} + 1} \right\rbrack} + {\left( {{- z} + 1001} \right)\left( 10^{- 6} \right)u\left\lbrack {z - 2} \right.}} \right){u\left\lbrack {{- z} + 1000} \right\rbrack}} +}} \\{\quad {{\left( {z + 1999} \right)\left( 10^{- 6} \right){u\left\lbrack {z + 1999} \right\rbrack}{u\left\lbrack {{- z} - 999} \right\rbrack}} + {\left( {{- z} + 1} \right)\left( 10^{- 6} \right)}}} \\{{\quad \left. {{u\left\lbrack {z + 998} \right\rbrack}{u\left\lbrack {- z} \right\rbrack}} \right)}{u\lbrack z\rbrack}{u\left\lbrack {{- z} + 999} \right\rbrack}} \\{= \quad {{\left( {z - 1} \right)\left( 10^{- 6} \right){u\left\lbrack {z - 1} \right\rbrack}{u\left\lbrack {{- z} + 999} \right\rbrack}} + {\left( {z + 999} \right)\left( 10^{- 6} \right)}}} \\{\quad {\left( {{\delta \lbrack z\rbrack} + {\delta \left\lbrack {z - 1} \right\rbrack}} \right) + {\left( {{- z} = 1001} \right)\left( 10^{- 6} \right){u\left\lbrack {z - 2} \right\rbrack}{u\left\lbrack {{- z} + 999} \right\rbrack}} +}} \\{\quad {\left( {{- z} + 1} \right)\left( 10^{- 6} \right)\left( {\delta \lbrack z\rbrack} \right)}} \\{= \quad {\left( 10^{- 6} \right)\left( {{\left( {\left( {z - 1} \right) + \left( {{- z} + 1001} \right)} \right){u\left\lbrack {z - 2} \right\rbrack}{u\left\lbrack {{- z} + 999} \right\rbrack}} +} \right.}} \\{\quad \left. {{\left( {z + 999} \right)\left( {{\delta \lbrack z\rbrack} + {\delta \left\lbrack {z - 1} \right\rbrack}} \right)} + {\left( {{- z} + 1} \right)\left( {\delta \lbrack z\rbrack} \right)}} \right)} \\{= \quad {\left( 10^{- 6} \right)\left( {{1000{u\left\lbrack {z - 2} \right\rbrack}{u\left\lbrack {{- z} + 999} \right\rbrack}} + {999{\delta \lbrack z\rbrack}} +} \right.}} \\\left. \left. {{\quad \left. {1000{\delta \left\lbrack {z - 1} \right\rbrack}} \right)} + {\delta \lbrack z\rbrack}} \right) \right) \\{= \quad {{1/1000}{u\lbrack z\rbrack}{u\left\lbrack {{- z} + 999} \right\rbrack}}}\end{matrix}$

[0171] Where δ[n] is the unit impulse function, defined to be 1 for n=0and 0 everywhere else. Finally, 1 is added to z to complete thecombination protocol, yielding:

p[result value]=1/1000u[result value−1]u[−result value+1000]

[0172] As is evident, if the player terminal chooses an integer in therange 1 to 1000, with each integer occurring with equal likelihood, andthe game server does the same, then each result value will occur withequal likelihood.

[0173] In this next example, the game server chooses the game serverrandom number in such a way that some game server random numbers aremore likely to occur than others. Perhaps the game server is attemptingto unduly influence the result value. In this example, the game serverwill choose the number 1 with probability a₁, the number 2 withprobability a₂, and so on. Note that a₁+a₂+a₃+ . . . +a₁₀₀₀=1, since thegame server is required to choose an integer between 1 and 1000,inclusively. Furthermore, all a's are between zero and 1, inclusively,since they represent probabilities. If, for instance, a₂=1, then thegame server will choose the number 2 with certainty, and there isactually no randomness at all in the game server's choice. Now, theprobability mass function for the game server random number can bewritten: $\begin{matrix}{{p\left\lbrack x_{g} \right\rbrack} = \quad {{a_{1}{\delta \left\lbrack {x_{g} - 1} \right\rbrack}} + {a_{2}{\delta \left\lbrack {x_{g} - 2} \right\rbrack}} + \ldots + {a_{1000}{\delta \left\lbrack {x_{g} - 1000} \right\rbrack}}}} \\{= \quad {\sum\limits_{k = {1\quad 1000}}{a_{k}{\delta \left\lbrack {x_{g} - k} \right\rbrack}}}}\end{matrix}$

[0174] Meanwhile, the player terminal chooses its number at random.Thus, the probability mass function for the player number remains:p[x_(p)]=1/1000u[x_(p)−1]u[−x_(p)+1000]. The combination protocol nowproceeds by taking y=x_(p)+x_(g). Once again $\begin{matrix}{{p\lbrack y\rbrack} = \quad {{p\left\lbrack x_{p} \right\rbrack}*{p\left\lbrack x_{g} \right\rbrack}}} \\{= \quad {{p\left\lbrack x_{p} \right\rbrack}*{\sum\limits_{k = {1\quad 1000}}\quad {a_{k}{\delta \left\lbrack {x_{g} - k} \right\rbrack}}}}} \\{= \quad {\sum\limits_{k = {1\quad 1000}}\quad {{p\left\lbrack x_{p} \right\rbrack}*a_{k}{\delta \left\lbrack {x_{g} - k} \right\rbrack}}}} \\{= \quad {\sum\limits_{k = {1\quad 1000}}\quad {\left( {{1/1000}{u\left\lbrack {x_{p} - 1} \right\rbrack}{u\left\lbrack {{- x_{p}} + 1000} \right\rbrack}} \right)*a_{k}{\delta \left\lbrack {x_{g} - k} \right\rbrack}}}} \\{= \quad {{1/1000}{\sum\limits_{k = {1\quad \ldots \quad 1000}}{a_{k}{u\left\lbrack {y - k - 1} \right\rbrack}{u\left\lbrack {{- \left( {y - k} \right)} + 1000} \right\rbrack}}}}} \\{= \quad {{1/1000}{\sum\limits_{k = {1\quad 1000}}{a_{k}{u\left\lbrack {y - k - 1} \right\rbrack}{u\left\lbrack {{- y} + k + 1000} \right\rbrack}}}}} \\{\quad {{{Once}\quad {again}},{{{let}\quad z} = {y\quad {modulo}\quad 1000.\quad {Now}}},}} \\{{p\lbrack z\rbrack} = \quad {{1/1000}{\sum\limits_{k = {1\quad 1000}}\left( {{a_{k}{u\left\lbrack {z - k - 1} \right\rbrack}{u\left\lbrack {{- z} + k + 1000} \right\rbrack}} +} \right.}}} \\{\quad {{a_{k}{u\left\lbrack {\left( {z + 1000} \right) - k - 1} \right\rbrack}{u\left\lbrack {{- \left( {z + 1000} \right)} + k + 1000} \right\rbrack}} +}} \\{\quad \left. {a_{k}{u\left\lbrack {\left( {z + 2000} \right) - k - 1} \right\rbrack}{u\left\lbrack {{- \left( {z + 2000} \right)} + k + 1000} \right\rbrack}} \right)} \\{\quad {{u\lbrack z\rbrack}{u\left\lbrack {{- z} + 999} \right\rbrack}}} \\{= \quad {{1/1000}{\sum\limits_{k = {1\quad 1000}}\left( {{a_{k}{u\left\lbrack {z - k - 1} \right\rbrack}{u\left\lbrack {{- z} + k + 1000} \right\rbrack}} +} \right.}}} \\{\quad {{a_{k}{u\left\lbrack {z - k + 999} \right\rbrack}{u\left\lbrack {{- z} + k} \right\rbrack}} + {a_{k}{u\left\lbrack {z - k + 1999} \right\rbrack}}}} \\{{\quad \left. {u\left\lbrack {{- z} + k - 1000} \right\rbrack} \right)}{u\lbrack z\rbrack}{u\left\lbrack {{- z} + 999} \right\rbrack}} \\{= \quad {{1/1000}{\sum\limits_{k = {1\quad {.1000}}}\left( {a_{k}{u\left\lbrack {z - k + 1999} \right\rbrack}{u\left\lbrack {{- z} + k + 1000} \right\rbrack}} \right)}}} \\{\quad {{u\lbrack z\rbrack}{u\left\lbrack {{- z} + 999} \right\rbrack}}} \\{= \quad {{1/1000}{\sum\limits_{k = {1\quad 1000}}{a_{k}{u\lbrack z\rbrack}{u\left\lbrack {{- z} + 999} \right\rbrack}}}}} \\{= \quad {{1/1000}{u\lbrack z\rbrack}{u\left\lbrack {{- z} + 999} \right\rbrack}{\sum\limits_{k = {1\quad 1000}}a_{k}}}} \\{= \quad {{1/1000}{u\lbrack z\rbrack}{u\left\lbrack {{- z} + 999} \right\rbrack}}}\end{matrix}$

[0175] Finally, 1 is added to z to complete the combination protocol,yielding:

p[result value]=1/1000u[result value−1]u[−result value+1000]

[0176] Once again, it is evident that all result values are equallylikely to occur. This, despite the fact that the game server wasattempting to influence the result value by more heavily favoring somepotential game server numbers over others. However, since the playerterminal did not favor one particular player number over another, allresult values were still equally likely to occur. Note that the aboveanalysis requires that the game server number and the player number begenerated independently. If the numbers are not generated independently,than both may have uniform probability mass functions over the closedinterval 1 to 1000, and yet their sum might be deterministic. Forexample, the game server may generate it's number randomly, and then theplayer terminal may generate its number according to the rule:x_(p)=1001−x_(g). Then the sum of the player number and the game servernumber will always be 1001.

[0177] The above analysis has shown that, according to at least onecriterion, the analyzed combination protocol is fair. That is, one partycannot change the probability of the occurrence of any result value, solong as the other party generates his number at random and according toa uniform probability mass function over a particular interval. Theanalysis could easily be extended to show that any combination protocolthat

[0178] 1) Adds a player and game server random number, each restrictedto a designated continuous interval, to generate a number y;

[0179] 2) Takes y modulo the length of the interval to generate a numberz; and

[0180] 3) And adds a constant to obtain the result value such that theresult value is certain to fall within the designated interval; is afair protocol according to the at least one criterion.

[0181] An example of an unfair combination protocol might be thefollowing:

[0182] 1) The player terminal and the game server each generate a numberthat is an integer between 1 and 500, inclusively; and

[0183] 2) The combination protocol adds the numbers together to get theresult value. The result value is to fall within the range 2 to 1000.

[0184] With the above protocol, the game server might choose the number499. Now, no matter what the player terminal chooses, the result valuecannot be 1000. This is because the player terminal is restricted tochoosing numbers in the range 1 to 500. Choosing the maximum number inthe range would only give a result value of 999, one short of 1000.Furthermore, no matter what the player terminal chooses, the resultvalue cannot be a number less than 500. So by purposely choosing aparticular number, the game server can assure that certain result valuescannot occur. Perhaps the result value of 1000 corresponds to a highpaying symbol combination in a game of slots. The player is then deniedthe opportunity to achieve this payout.

[0185] A typical combination protocol may be more complicated than thoseanalyzed above. As such, the fairness of the protocol may notnecessarily be determinable through a simple analysis. One way for, say,a player terminal to verify the fairness of a combination protocolalgorithm would be to run the algorithm using all possible combinationsof inputs (i.e. all possible combinations of player and game servernumbers). The player terminal could check that given a particular gameserver random number, all possible result values might still occur. Theplayer terminal might further verify that a for a particular resultvalue, rv₀, and any two game server numbers x_(g1) and x_(g2), thechances of rv₀ occurring given x_(g1) are the same as the chances of rv₀occurring given x_(g2). This may assume that the player himselfgenerates the player number at random, with all numbers equally favoredprobabilistically.

[0186] Another method of verifying that a combination protocol algorithmis fair would be for a player to run the algorithm many times with arandom player number and a fixed game server number. The player wouldthen check to see whether or not particular result values were undulyfavored or disfavored. If, for example, a player ran the combinationprotocol many times with a fixed game server number and a random playernumber, and found that a particular result value never occurred, thenthe player might determine that the combination protocol is unfair. Thismethod of verification may be used right after the completion of a game,such as a spin at a slot machine. Perhaps the player has lost the gameand is suspicious that he has been cheated due to an unfair combinationprotocol. So the player tests the game server random number from thegame with numerous possible player numbers. The test should show theplayer what might have happened had the player chosen a different playernumber in the game. If it turns out that no player number would haveresulted in a favorable result value for the player, then the player hasconfirmed the unfairness of the combination protocol.

[0187] One or more embodiments of the present invention provide forevaluating the fairness of a combination protocol by determining a setof at least one generated game outcome as described above anddetermining a relative frequency which a particular game outcome occursin the set of at least one generated game outcome. A probability of thatparticular game outcome occurring in a fair game (e.g., a game in whichone of the parties cannot inappropriately influence the outcome and/orthe random process used to determine an outcome) may also be determined.Then, a level of fairness of the combination protocol can be determinedbased on the probability of the outcome occurring in a fair game and therelative frequency of representation. For example, the probability andthe relative frequency of representation can be compared. If there is adifference between the relative frequency in the generated outcomes andthe probability of the outcome occurring in a “pure” game, the level offairness may depend on the difference. Any difference, for example, maybe compared to a predetermined allowable difference. It will beunderstood that the probability and the relative frequency need not beexactly the same, but may vary by an allowable margin.

[0188] Various levels of fairness may correspond to how much therelative frequency and the probability vary. For example, a slightdifference may correspond to a fairness of “Very Fair”, and a largerdifference may correspond to a fairness level of “Unfair.”

[0189] For example, a player is to test a combination protocol forfairness using a fixed number (e.g., a game server number) and each of aset of one or more possible player numbers. To determine a set ofpossible player numbers to use, a given set may be compared with one ormore various criteria, to determine whether the set of player numbers,if tested, would provide the predetermined degree of confidence that thecombination protocol is fair.

[0190] An evaluation of the fairness of a combination protocolpreferably includes a sufficient number of tests so that the failure ofthe appearance of the predetermined game outcome the predeterminednumber of times would most likely indicate the unfairness of thecombination protocol. Otherwise, the failure to generate certain resultvalues and/or outcomes during analysis of a combination protocol mightbe explained by the lack of a sufficient number of tests of thecombination protocol, and not necessarily by the unfairness of thecombination protocol itself.

[0191] Accordingly, one criterion for selecting a set of player numbersto test with may be that the number of elements in the set of playernumbers is not less than some threshold or predetermined minimum numberof elements.

[0192] Similarly, another criterion for the set of player numbers testedmight by that the number of elements in the set of player numbers is notless than a predetermined minimum percentage (e.g., 10%, 100%) of thenumber of all allowed player numbers. Again, this criterion might helpto ensure that the failure of a test to generate a particular resultvalue and/or outcome tests is most likely due to the unfairness of thecombination protocol, and not to the lack of a sufficient number oftests conducted.

[0193] Another possible criterion for the set of player numbers testedmight be that the number of elements in the set of player numbers issufficient such that, if each player number tested leads to acorresponding game outcome, then the number of elements in the set ofplayer numbers will ensure, with a predetermined probability, at least apredetermined number of occurrences of a particular game outcome.

[0194] Further criteria might require that the player numbers in the setof player numbers tested must all be distinct, and/or that each of theplayer numbers must be selected at random from among all allowed playernumbers.

[0195] Many other such criteria for the set of player numbers to betested will be obvious to those having ordinary skill in the art.

[0196] Although several methods of verifying the fairness of acombination protocol have been described, many other methods arepossible. Methods for verifying the fairness of a combination protocolmay also be used to verify the fairness of a player or game serveralgorithm in embodiments where the player and the game server exchangealgorithms rather than numbers.

[0197] Various embodiments of the present invention are directed tosystems and methods for ensuring the randomness of random numbers. Oneor more embodiments of the present invention provide for authenticatingthe results of electronic games in a manner that substantially obviatesone or more of various limitations and disadvantages of the related art.Various embodiments of the present invention provide, in an electronicgame system, hardware and procedures to ensure that random numbers usedto generate game results are truly random, independently-generatednumbers.

[0198] In accordance with one or more embodiments of the presentinvention, an electronic game system comprises a game server and one ormore player terminals. The game server includes a random numbergenerator and a first transmitting device for transmitting a firstrandom number to the one or more player terminals. The one or moreplayer terminals includes a random number generator and a secondtransmitting device for transmitting a second random number to the gameserver. The system also includes one or more of various hardware and/orprocedures for ensuring that the first random number is generatedindependently of the second random number.

[0199] One or more embodiments of the present invention provide for amethod for controlling an electronic game played in a system thatincludes a game server and one or more player terminals. The methodincludes the steps of generating a first random number at the gameserver; generating a second random number at the player terminal;encoding the first random number at the game server; encoding the secondrandom number at the player terminal; transmitting a player encodednumber from the player terminal to the game server; transmitting aplayer decoding key from the player terminal to the game server; anddecoding the player encoded number at the game server to obtain thesecond random number.

[0200] According to various embodiments of the present invention, aresult value is generated based on the first random number and thesecond random number. Some embodiments of the present invention providefor producing a game result based on the result value.

[0201] Some embodiments of the present invention are directed to varioussystems and procedures of a game server separate from a player terminal,as well as various combinations of such systems and/or procedures. Someembodiments of the present invention are directed to various systems andprocedures of a player terminal separate from a game server, as well asvarious combinations of such systems and/or procedures. As discussedabove, other embodiments may provide for one or more systems and/orprocedures of a game server in various combinations with one or moresystems and/or procedures of a player terminal.

[0202] One or more embodiments of the present invention provide forvarious hardware and/or procedures for encoding, hashing, encrypting,decoding, dehashing, and decrypting the first and second random numbers.Moreover, one or more embodiments of the systems and procedures of thepresent invention provide for authenticating players. One or moreembodiments of the present invention provide for creating audit recordsof game data.

[0203] While there has been illustrated and described what are atpresent considered to be preferred embodiments and methods of thepresent invention, it will be understood by those skilled in the artthat various changes and modifications may be made, and equivalents maybe substituted for elements thereof without departing from the truescope of the invention.

[0204] Respective objects and advantages of various embodiments of theinvention will be obvious from the description, or may be learned bypractice of the invention. It is to be understood that descriptionsprovided herein are exemplary and explanatory only, and are notrestrictive of the invention, as claimed.

[0205] In addition, many modifications may be made to adapt a particularelement, technique or implementation to the teachings of the presentinvention without departing from the central scope of the invention.Therefore, it is intended that this invention not be limited to theparticular embodiments and methods disclosed herein, but that theinvention include all embodiments failing within the scope of theappended claims.

What is claimed is:
 1. A game server, comprising: a processor; and astorage device coupled to the processor and storing instructions adaptedto be executed by the processor to perform a method comprising:generating a first signal; transmitting an encoded first signal;receiving a second signal; and transmitting a decoding key afterreceiving the second signal, the decoding key enabling a player terminalto determine the first signal.
 2. The game server of claim 1, in whichthe first signal comprises a number.
 3. The game server of claim 1, inwhich the first signal comprises a random number.
 4. The game server ofclaim 1, in which the first signal comprises a letter.
 5. The gameserver of claim 1, in which the first signal comprises a word.
 6. Thegame server of claim 1, in which the first signal comprises an audiosignal.
 7. The game server of claim 1, in which the first signalcomprises an video signal.
 8. The game server of claim 1, in which thefirst signal comprises an algorithm.
 9. The game server of claim 1,further comprising: a communication port coupled to said processor andadapted to communicate with at least one player terminal.
 10. A mediumstoring instructions adapted to be executed by a processor to perform amethod, the method comprising: generating a first signal; transmittingan encoded first signal; receiving a second signal; and transmitting adecoding key after receiving the second signal, the decoding keyenabling a player terminal to determine the first signal.
 11. A methodcomprising: determining a first signal; receiving an encoding key from athird party; encoding the first signal based on the encoding key togenerate an encoded first signal; transmitting the encoded first signalto a player terminal; receiving a second signal from the playerterminal; and transmitting a decoding key to the player terminal afterreceiving the second signal.
 12. The method of claim 11, in which theencoding key is generated by the third party.
 13. A method comprising:receiving an encoded first signal from a player terminal, in which theencoded first signal comprises a first signal that is encoded;generating a second signal; receiving an encoding key from a thirdparty; encoding the second signal to generate an encoded second signal;transmitting the encoded second signal to the player terminal; receivinga decoding key from the player terminal after transmitting the secondsignal; and determining the first signal based on the encoded firstsignal and the decoding key.
 14. A method comprising: receiving anencoded first signal from a player terminal, in which the encoded firstsignal comprises a first signal that is encoded; receiving a decodingkey from the player terminal; determining the first signal based on theencoded first signal and the decoding key; transmitting a request forverification of the first signal to a third party, the request includingthe decoding key; and receiving from the third party an indication ofwhether the first signal is verified.
 15. The method of claim 14,further comprising: determining a second signal; and transmitting thesecond signal to the player terminal.
 16. The method of claim 15, inwhich receiving the decoding key comprises: receiving the decoding keyfrom the player terminal after transmitting the second signal.
 17. Themethod of claim 14, further comprising: determining a second signal;encoding the second signal to generate an encoded second signal; andtransmitting the encoded second signal to the player terminal.
 18. Themethod of claim 17, in which receiving the decoding key comprises:receiving the decoding key from the player terminal after transmittingthe encoded second signal.
 19. The method of claim 14, in whichreceiving from the third party an indication of whether the first signalis verified comprises: receiving from the third party an indication ofwhether the decoding key corresponds to an encoding key that isassociated with the player terminal.
 20. The method of claim 19, inwhich the encoding key is generated by the third party.
 21. A methodcomprising: receiving an encoded first signal from a player terminal, inwhich the encoded first signal comprises a first signal that is encoded;receiving a decoding key from the player terminal; determining the firstsignal based on the encoded first signal and the decoding key;transmitting a request for verification of the first signal to a thirdparty, the request including the encoded first signal, and the requestincluding the first signal; and receiving from the third party anindication of whether the first signal is verified.
 22. The method ofclaim 21, further comprising: determining a second signal; andtransmitting the second signal to the player terminal.
 23. The method ofclaim 22, in which receiving the decoding key comprises: receiving thedecoding key from the player terminal after transmitting the secondsignal.
 24. The method of claim 21, further comprising: determining asecond signal; encoding the second signal to generate an encoded secondsignal; and transmitting the encoded second signal to the playerterminal.
 25. The method of claim 24, in which receiving the decodingkey comprises: receiving the decoding key from the player terminal aftertransmitting the encoded second signal.
 26. The method of claim 21, inwhich receiving from the third party an indication of whether the firstsignal is verified comprises: receiving a fraud signal from the thirdparty.
 27. The method of claim 21, further comprising: receiving anencoding key from the third party.
 28. The method of claim 27, in whichthe encoding key is generated by the third party.
 29. A methodcomprising: receiving a first encoded first signal from a playerterminal, in which the first encoded first signal comprises a firstsignal that is encoded; receiving a decoding key; determining the firstsignal based on the first encoded first signal and the decoding key;transmitting a request for an encoding key to a third party; receivingthe encoding key from the third party; and determining whether theencoding key corresponds to the decoding key.
 30. The method of claim29, in which the encoding key is generated by the third party.
 31. Themethod of claim 29, in which the encoding key is associated with theplayer terminal.
 32. The method of claim 29, in which determiningwhether the encoding key corresponds to the decoding key comprises:determining whether the encoding key and the decoding key define inversefunctions.
 33. The method of claim 29, in which determining whether theencoding key corresponds to the decoding key comprises: encoding thefirst signal based on the encoding key to generate a second encodedfirst signal; and determining whether the second encoded first signal isequal to the first encoded first signal.
 34. The method of claim 29,further comprising: transmitting a fraud signal to the player terminalif the encoding key does not correspond to the decoding key.
 35. Themethod of claim 29, further comprising: determining a second signal; andtransmitting the second signal to the player terminal.
 36. The method ofclaim 29, in which receiving the decoding key comprises: receiving thedecoding key from the player terminal after transmitting the secondsignal.
 37. The method of claim 29, further comprising: determining asecond signal; encoding the second signal to generate an encoded secondsignal; and transmitting the encoded second signal to the playerterminal.
 38. The method of claim 37, in which receiving the decodingkey comprises: receiving the decoding key from the player terminal aftertransmitting the encoded second signal.
 39. A method comprising:receiving an encoded first signal from a player terminal, in which theencoded first signal comprises a first signal that is encoded;generating a second signal; transmitting the second signal to the playerterminal; receiving a decoding key from the player terminal aftertransmitting the second signal; determining the first signal based onthe encoded first signal and the decoding key; and before transmittingthe second signal, receiving an encoding key from the player terminal.40. A method comprising: generating a first signal; determining anencoding key; generating an encoded first signal based on the firstsignal and the encoding key; transmitting the encoded first signal to aplayer terminal; determining a second signal that is associated with theplayer terminal; and before determining the second signal, transmittingthe encoding key to the player terminal.
 41. The method of claim 40,further comprising: transmitting a decoding key to the player terminalafter receiving the second signal.
 42. The method of claim 40, in whichdetermining the encoding key comprises: receiving the encoding key froma third party.
 43. The method of claim 40, in which determining thesecond signal comprises: receiving the second signal from the playerterminal.
 44. The method of claim 40, in which determining the secondsignal comprises: receiving an encoded second signal from the playerterminal, in which the encoded second signal comprises the second signalin an encoded format; and receiving a decoding key from the playerterminal.
 45. A method comprising: generating a first signal;determining at least one character; combining the first signal and theat least one character to generate a combination of the first signal andthe at least one character; encoding the combination to generate anencoded combination; transmitting the encoded combination to a playerterminal; receiving a second signal from the player terminal; andtransmitting a decoding key to the player terminal after receiving thesecond signal.
 46. The method of claim 45, in which combining comprises:appending the at least one character to an end of the first signal. 47.The method of claim 45, in which combining comprises: appending a firstcharacter to a first end of the first signal; and appending a secondcharacter to a second end of the first signal.
 48. A method comprising:receiving an encoded combination from a player terminal, in which theencoded combination comprises a combination that is encoded, and inwhich the combination comprises a first signal and at least onecharacter; generating a second signal; transmitting the second signal tothe player terminal; receiving a decoding key from the player terminalafter transmitting the second signal; and determining the at least onecharacter based on the encoded combination and the decoding key.
 49. Themethod of claim 48, further comprising: determining whether the at leastone character matches a predetermined at least one character.
 50. Themethod of claim 49, further comprising: receiving an indication of thepredetermined at least one character from the player terminal.
 51. Themethod of claim 49, further comprising: selecting the predetermined atleast one character; and transmitting an indication of the predeterminedat least one character to the player terminal.
 52. The method of claim48, in which the at least one character comprises a letter.
 53. Themethod of claim 48, in which the at least one character comprises anumber.
 54. The method of claim 48, in which the at least one charactercomprises a word.
 55. A medium storing instructions adapted to beexecuted by a processor to perform a method, the method comprising:generating a first signal; encoding the first signal to generate anencoded first signal; transmitting the encoded first signal to a gameserver; receiving a second signal from the game server; and transmittinga decoding key to the game server after receiving the second signal, thedecoding key enabling the game server to determine the first signalbased on the encoded first signal and the decoding key.
 56. A playerterminal, comprising: a processor; and a computer readable mediumstoring a program, the program being operative to instruct the processorto perform a method comprising: receiving an encoded first signal, inwhich the encoded first signal comprises a first signal that is encoded;generating a second signal; transmitting the second signal; receiving adecoding key after transmitting the second signal; and determining thefirst signal based on the encoded first signal and the decoding key. 57.The player terminal of claim 56, further comprising: a communicationport coupled to the processor and adapted to communicate with at leastone game server.
 58. A medium storing instructions adapted to beexecuted by a processor to perform a method, the method comprising:receiving an encoded first signal from a game server, in which theencoded first signal comprises a first signal that is encoded;generating a second signal; transmitting the second signal to the gameserver; receiving a decoding key from the game server after transmittingthe second signal; and determining the first signal based on the encodedfirst signal and the decoding key.
 59. A method comprising: transmittingan encoding key to a game server; receiving a request for verificationfrom a player terminal, the request including a decoding key;determining whether the encoding key corresponds to the decoding key;and transmitting to the player terminal an indication of whether theencoding key corresponds to the decoding key.
 60. The method of claim59, further comprising: generating the encoding key.
 61. The method ofclaim 59, in which the decoding key is associated with the game server.62. The method of claim 59, in which determining comprises: determiningwhether the encoding key and the decoding key define inverse functions.63. The method of claim 59, in which determining comprises: determininga first number; encoding the first number based on the encoding key togenerate an encoded first number; decoding the encoded first numberbased on the decoding key to generate a second number; and determiningwhether the second number is equal to the first number.
 64. The methodof claim 59, in which transmitting to the player terminal the indicationof whether the encoding key corresponds to the decoding key comprises:transmitting a fraud signal to the player terminal if the encoding keydoes not correspond to the decoding key.
 65. The method of claim 59,further comprising: transmitting the encoding key to the playerterminal.
 66. The method of claim 59, further comprising: transmitting afraud signal to the game server if the encoding key does not correspondto the decoding key.
 67. A method comprising: transmitting an encodingkey to a game server; receiving an encoded first signal from a playerterminal, in which the encoded first signal comprises a first signalthat is encoded; receiving a second signal; encoding the second signalbased on the encoding key to generate an encoded second signal;determining whether the encoded second signal is equal to the encodedfirst signal; and transmitting to the player terminal an indication ofwhether the encoded second signal is equal to the encoded first signal.68. The method of claim 67, further comprising: generating the encodingkey.
 69. The method of claim 67, in which transmitting to the playerterminal the indication of whether the encoded second signal is equal tothe encoded first signal comprises: transmitting a fraud signal to theplayer terminal if the encoded second signal is not equal to the encodedfirst signal.
 70. The method of claim 67, further comprising:transmitting the encoding key to the player terminal.
 71. The method ofclaim 67, in which receiving the second signal comprises: receiving thesecond signal from the game server.
 72. The method of claim 67, in whichreceiving the second signal comprises: receiving the second signal fromthe player terminal.
 73. The method of claim 67, further comprising:transmitting a fraud signal to the game server if the encoded secondsignal is not equal to the encoded first signal.
 74. A methodcomprising: determining at least one potential game outcome, in whichthe at least one potential game outcome corresponds to a game;determining a combination protocol for generating a game outcome, inwhich the combination protocol is associated with the game, in which thecombination protocol has an associated first input, and in which thecombination protocol has an associated second input; determining atleast one first number; determining a second number; generating, foreach at least one first number, a respective game outcome based on: thefirst number, the second number, and the combination protocol, therebydetermining a set of at least one generated game outcome; anddetermining whether each at least one potential game outcome isrepresented in the set of the at least one generated game outcome. 75.The method of claim 74, in which generating comprises: generating, foreach at least one first number, a respective result value based on: thefirst number, the second number, and the combination protocol, therebydetermining a set of at least one result value.
 76. The method of claim75, further comprising: determining, for each result value of the set ofat least one result value, a respective game outcome that corresponds tothe result value, thereby determining the set of at least one generatedgame outcome.
 77. The method of claim 74, further comprising: receivingan indication of a table associating result values and respectiveoutcomes; and in which generating comprises: generating, for each atleast one first number, the respective game outcome based on: the firstnumber, the second number, the table, and the combination protocol. 78.The method of claim 77, in which the table is a payout table.
 79. Themethod of claim 74, in which determining the set of potential gameoutcomes comprises: determining a payout table that is associated withthe game.
 80. The method of claim 74, further comprising: determining acriterion that is associated with the first input; determining a set ofinputs that satisfy the criterion; and in which determining the at leastone first number comprises: selecting the at least one first number fromthe set of inputs that satisfy the criterion.
 81. The method of claim74, in which determining the at least one first number comprises:determining a set of the at least one first number, the set having anumber of elements that is not less than a predetermined minimum numberof elements.
 82. The method of claim 74, further comprising: determininga criterion that is associated with the first input; determining anumber of inputs that satisfy the criterion; and in which determiningthe at least one first number comprises: determining a set of the atleast one first number, the set having a number of elements that is notless than a predetermined minimum percentage of the number of inputsthat satisfy the criterion.
 83. The method of claim 74, in whichdetermining the combination protocol comprises: receiving an indicationof the combination protocol from a game server.
 84. The method of claim74, in which determining the combination protocol comprises: selectingthe combination protocol from a plurality of combination protocols. 85.The method of claim 74, in which determining the second numbercomprises: receiving the second number from a game server.
 86. Themethod of claim 74, in which determining the second number comprises:receiving the second number from a player terminal.
 87. A methodcomprising: determining a combination protocol for generating a gameoutcome, in which the combination protocol is associated with a game, inwhich the combination protocol has an associated first input, and inwhich the combination protocol has an associated second input;determining a first criterion that is associated with the first input;determining at least one first number that satisfies the firstcriterion; determining a second number; generating, for each at leastone first number, a respective game outcome based on: the first number,the second number, and the combination protocol, thereby determining aset of at least one generated game outcome; and determining a potentialgame outcome, in which the potential game outcome is associated with thegame; determining a probability of occurrence of the potential gameoutcome; determining a relative frequency of representation of thepotential game outcome in the set of at least one generated gameoutcome; and determining a level of fairness of the combination protocolbased on the probability of occurrence and the relative frequency ofrepresentation.
 88. The method of claim 87, in which determining thelevel of fairness comprises: comparing the probability of occurrence andthe relative frequency of representation.
 89. The method of claim 87, inwhich determining the level of fairness comprises: determining adifference between the probability of occurrence and the relativefrequency of representation; and determining whether the difference isgreater than a predetermined difference.